エンジニアリングの規律Claude Code and other supported coding agents
Jesse Vincent (obra) / test-driven-development
テスト駆動開発が、人だけのときよりエージェントで効くのはなぜか
失敗するテストが、依頼を正しく理解したことを示す唯一の証拠だからです。
押さえておく点
- 失敗するテストは、言葉でかわせない仕様です。
- 失敗を目で見てください。いきなり緑になる場合、失敗し得ないテストが書かれています。
- 小さな周期が本質です。大きな周期はテストなしと同じ誤った安心を与えます。
- より広い方法論の一部であり、writing-plans と併用すると効きます。
01実務で何が変わるか
エージェント支援の開発で難しいのは能力ではなく検証です。エージェントは成功したと信じ、差分は妥当に見え、誰も何も確認していません。失敗するテストは、その信念を機械的な事実に変えます。
誤解の発見も前倒しになります。エージェントが誤った挙動を主張するテストを書いたなら、大きな実装が積み上がった後ではなく最初の 1 分で分かります。
02期待に届かない点
実装がたまたましている動作をそのまま主張するテストは、テストなしより有害です。欠陥をその場に固定するからです。結果だけでなくテスト本文を読んでください。
探索とも相性が悪いです。正解の形がまだ分からない段階で先にアサーションを書くのは、手順を増やした当てずっぽうです。
導入と最初の実行
- obra/superpowers から MIT ライセンスで superpowers を導入します。
- 実装が書かれる前に、テストが失敗するところを必ず見せさせます。
- 1 周期を小さな挙動 1 つに保ちます。周期が大きいと、何が失敗したのかが隠れます。
実際によくある質問
- なぜ失敗を目で見る必要がありますか
- 実装前に通るテストは何も検証していません。失敗を確認するのが最も安い点検です。
- エージェントの速度は落ちますか
- 変更単位では落ちます。1 週間単位ではたいてい速くなります。未検証の変更による手戻りが消えるからです。
- superpowers の他と切り離せますか
- 大きな方法論の中の 1 スキルです。単体でも動き、writing-plans や verification-before-completion と併用するとより効きます。
出典
このページの機械可読版