tdd-identify

1 行での概要

今の状況にどの TDD テクニックが適しているかを診断します。適切な Beck の手法は、何を入力すればよいかわかっているか、テストが大きすぎるか、依存先が遅すぎるか、あるいはバグを見つけたばかりかによって変わります。

このスキルを使う場面

• テストが失敗していて、どうすれば成功するかわかりません。
• 実装は見えているものの、そのまま入力するか、まず偽物を作ってから一般化するか判断できません。
• 次のテストを前にして、どれを書くべきか決められません。
• テストが遅い／外部の依存先にアクセスしていて、どう分離すればよいかわかりません。
• バグを修正したばかりで、どのようなテストを残せばよいかわかりません。

このスキルを使わない場面

• そもそも TDD を使うかどうか決めていません → それはワークフローに関する問題です。tdd-red-green-refactor を参照してください（Superpowers の test-driven-development がインストールされている場合はそちらも参照してください）。
• 適用するテクニックが明確にわかっています → そのスキルに直接進んでください。
• TDD に関する問題に見せかけたドメインモデリングの問題です → ddd-design に進んでください。

主な内容

行き詰まっている状況を、次の質問で順番に確認します。

1. テストが失敗していて、どんなコードを書けばよいかわかりませんか？

• 本番コードがどのようなものか正確にわかっています → tdd-obvious-implementation。そのまま入力してください。
• この入力に対する答えはわかっていますが、一般的なアルゴリズムはわかりません → tdd-fake-it。定数を返し、次のテストで一般化を促します。
• 偽物を作ったので、今度は一般化する必要があります → tdd-triangulate。異なる入力で、偽物では通らない 2 つ目のテストを書いてください。

2. 書こうとしているテストが大きすぎると感じますか？

• このテストに対応する本番コードの書き方が見えません → tdd-child-test。大きなテストはいったん脇に置き、完了できる小さなテストを書きます。新たな理解を得てから、大きなテストに戻ります。
• テストのバックログがあり、次にどれを書くべきかわかりません → tdd-one-step-test。すぐに実装できる範囲で、最も多くの学びが得られるテストを選んでください。

3. テストが遅い／外部の／信頼性に欠けるものに触れていますか？

• データベース、ネットワーク、ファイルシステム、時刻 → tdd-mock-object。テストダブルを使い、本物に対するテストもどこかで行ってください。
• 単独で実行すると成功するのに、まとめて実行すると失敗します → tdd-test-isolation。各テストがそれぞれのフィクスチャを所有するようにします。変更可能な状態を共有してはいけません。

4. 十分に理解していないサードパーティーライブラリを使っていますか？

• このライブラリの挙動がわかりません。ドキュメントだけでは不十分です → tdd-learning-test。ライブラリの挙動を確かめ、アップグレード時の破壊的変更を検知するためのテストを書いてください。

5. バグを修正したばかりですか？

• すべてのバグにテストを作ります → tdd-regression-test。そのバグを検知できたはずのテストを書き、修正と一緒にコミットしてください。

6. テストの問題点を確認していますか？

• 遅いテスト、不安定なテスト、相互依存するテスト、自分が所有していないもののモック化、コードではなくフレームワークをテストしていること → tdd-anti-patterns で監査してください。

判断のヒント

• Beck 自身の判断ツリー（要約）：「何を入力すればよいかわかっているなら、それを入力する（obvious-implementation）。1 つのケースの答えはわかっているが、それ以外はわからないなら、fake-it。どちらでもないなら、triangulate。それでも行き詰まるなら、シャワーを浴びる。」
• mock-object は慎重に使ってください。モックはテストを実装に結び付けます。境界（外部サービス、遅いリソース、時刻）でのみモックを使います。
• テストの規模に迷ったら、常に child-test を選んでください。小さなテストのほうが早く学べます。

アンチパターン

• 各テクニックを「卒業すべきレベル」として扱うこと。obvious-implementation は fake-it より優れているわけではありません。それぞれ異なる状況で使うものです。経験豊富な実践者は、どちらも使いこなします。
• 反射的にすべてをモック化すること。モックは最後の手段であり、標準の方法ではありません。
• 修正後に regression-test の手順を省略すること。バグが再発しても、検知するものがありません。

関連項目

• このプラグインにある他の tdd-* スキル 11 個すべて。上記の各案内はそのうちの 1 つを参照しています。
• Superpowers の superpowers:test-driven-development（インストールされている場合）—「今すぐ TDD を使う」というワークフローレベルのトリガーです。

参考資料

• Kent Beck 著、Test-Driven Development By Example（Addison-Wesley、2002年）— 第III部は、標準的なパターン集です。
• Beck 自身による「rules」のエッセイと、TDD に関するカンファレンストーク。