阿部です。
>> というパターンです。なんせ上司の目があるので、テストコードを書くのに
>> 時間を取られて機能の実装が遅い、というのはご法度ですから、執拗なテスト
>> などというものは後回しになります。
>>
>上司の目は関係ないでしょう。
>テストする項目は、失敗しそうなすべてのことです。
進捗が気になってしょうがないのは上司の常では？と思ってるんですが。
ですから、テストの半分くらい（エラーコードが帰ってくるパターンとか）
は後回しにして、基本的なテストを先に書いてから機能の実装に入ります。
テスト項目として考え付く全パターンは最終的には挙げますけど、
私の場合「テスト・ファースト」は半分しか守らずに複雑なテストは
後回しにする、という事です。理由の半分は、全テストを最初に列挙する
ほど頭が良くない、という事です。正直言って、コードを書きながら有効な
テストを思いつくことも多いです。
後半分は、複数のメソッドを利用するテスト（別発言にあるＤＢアクセスとか）
などは、例えばinsertとselectが両方実装できていないとテストが成功しない、
という意味では単体の実装より後回しにしているという事です。
基準としては、１日、あるいは数時間でメソッドの実装を終えられないテストは
せめて必要なメソッドがそろってから実装する、としています。
そうすることで「テスト・ファースト」は破られてしまいますが、毎日
ほぼ確実にテストが１００％成功するコードをコミットできます。
XPで「テスト・ファースト」が重要であっても、私的なプライオリティでは
「テストに成功したものだけをコミットする」という方が重要です。これは
チーム開発する上でCVSを用いて開発している関係上、動きもしないコードを
コミットされると困る、との判断からです。
と同時に、XP自体の導入を１つ１つ試して効果を見ながら行っている関係上、
いきなりチーム全員に厳密な（書籍に書いてあるとおりの）XPの全プラクティス
を守らせることはできませんから、徐々に楽な方向から、チームに合った、
できうる限りのプラクティスを盛り込んだ形に徐々に変えていく、というスタイル
を取っています。いずれは「テスト・ファースト厳守」というスタイルになる
かもしれませんけど、今はまだ様子見、という事です。
-------------------------------------------------------------
Takashi Abe <abetaka@....jp>
HP: http://homepage1.nifty.com/taka-page/
合気道 薫友会 : http://homepage2.nifty.com/kun-yu/index.html
-------------------------------------------------------------