山田＠メタボリックスです。
At 11:34 +0900 00.12.9, Kaoru Hosokawa wrote:
>山田さんだけに送ってしまいました。
失礼いたしました。
Reply-Toは直しておきましたので...
>私は、ユニットテストの可能性を探っているようです。バグがでたら、それは、仕様
>（ユニットテスト）が不十分であったから、テストを追加して、曖昧なところをデバッ
>グできないか？こんな事を考えていました。
「バグが出たら」というのは「Unit Testをパスしなかったら」という意味じゃない
んですか?
その後の受け入れテストなどでバグが出たら、という意味なのか、もしかして。
じゃぁ、誤解していたかも知れません。
受け入れテスト後のデバグは、当然テスト・コードもテスト対象コードも
デバグしなければなりませんね。
そういうことだったのか...
分かりました。
> > テストとデバグを一つにするという方向もあるのかも知れませんが、
>> 今のUnit Test(Test firstのプラクティス)はそれとは違って、むしろ
>> それらを分離する方向にある、そしてそれは「よい」方向であると
> > 思うからです。
>そうですね。私の考えは、XPでのUnit Testの位置付けとは違います--少し飛んでま
>すかね？
いえ、前にも書いたように大変興味深く思いました。
あくまでUnit Testとは別のものとして...ですが。
ホソカワさんたちとの議論を通して、
Automatic Inspectionのようなプラクティスが有用なのではないか、と思い始めまし
た。
このInspectionはIBMのFaganに発するインスペクションのことです。
別のスレッドでKnuthのwebシステムが議論されているのと多少の共通点が
あるのかも知れません。
一つは静的なautomatic inspectionで、これはほぼCのlintみたいなものです。
バグっぽいところやリファクタリングすべきポイントを教えてくれる。
もう一つは動的なautomatic inspectionで、これはコードに対するメタ・コード
(そのコードが何を意味しているか、どう動くべきかをメタ・レベルのコードで書く)を
いつもペアで書いておいて、ツールに検証させます。
UnitTest: コード <-> テスト・コード
Automatic Inspection: コード <-> メタ・コード
二つの違いは仕様に関するものか、実装に関するものか、ということです。
時間ができたら試してみたいと思っていますが。
(XPではこれをペア・プログラミングで実現しているのかもしれない)
> > privateをUnit Testでテストするかどうかということに相似しているのかも知れ
>ませ
>> ん。
>> ちなみに僕は原則的にしないという方針です。
> ^^^^^^
>必要だったらするということですよね？:)
なはは:)
privateなメソッドには、UnitTestの観点からみて二つの種類があると思うのです。
一つは「操作の完全性からは必要だが、実用上外に見せない」
例えば外からいじられたくないsetterなんてそうですね。
もう一つは「完全に実装に依存していて、別の実装をすれば消えてしまう」
前者の意味でprivateなメソッドは僕の基準ではテスト対象です。
後者はリファクタリングでどんどん変わってしまうのでテスト・コードには
現れません。
こういうのが上で言ったautomatic inspectionの対象になると思っています。
僕の場合は、Javaで
1. インタフェースを書く
2. Meyerの意味での契約をJavaかOCL風に書いておく
3. それにもとづいてテスト・コードを書く
4. それにもとづいて実装コードを書く
というものなので、徹底的なボトムアップのXP風コーディング・スタイルとは
違っているのかも知れませんが。
(彼らの場合は最後にインタフェースが現れる!)
---
山田正樹, (有)メタボリックス
259-0111 神奈川県中郡大磯町国府本郷576-8
tel: 0463-60-2234 fax: 0463-60-2266
moblie: 090-8347-9605
http://www.metabolics.co.jp/