僕の考えるテストファースト開発技法
はじめに この記事では、ウォーターフォール開発を前提に、各工程でどのようにテストファースト的に振る舞うかを整理します。 テストファーストは実装だけの話じゃない Kent Beck のTDD（Test Driven Development）は「Red → Green → Refactor」で有名ですが、本質は「動く前に、どうあるべきかを定める」ことです。 つまりこの考え方は、要件定義・基本設計・詳細設計といった上流工程にも応用できます。 各工程とテストの対応・考え方 要件定義 × システムテスト 基本設計 × 結合テスト 詳細設計 × 単体テスト テストファースト思考の共通原則 メリット・デメリット メリット 項目 内容 要件漏れ防止 テスト視点でパターンを考えるため、漏れが減る 手戻り減少 実装後に「想定外のケース」に気づくリスクが下がる レビューがしやすい 期待値ベースで設計やコードをチェックできる チーム共通認識 テスト観点を通じて、仕様認識のずれを防げる デメリット 項目 内容 工数が見えづらい 「テスト設計思考」は明文化されにくい 重箱の隅になりがち 異常系ばかりに気を取られてしまうことも 経験が必要 網羅性の判断には経験が必要で、属人化しやすい まとめ テストファーストって、なんか「テストコードを先に書こうぜ」って話に見えがちだけど、僕としてはもっと広い意味で捉えてます。 実装に入る前に「こう動くべき」って期待値とかパターンをちゃんと考えとこうよっていうスタンスでそれが要件定義だろうが、基本設計だろうが、どのフェーズでも大事な姿勢だと考えました。 ただ、全部の工程で全員がそれを意識する必要があるかって言うと、別にそうでもなくて。リーダーとかレビュアーがそういう視点を持って、レビューや方針決めのときにちゃんと網羅性とか「抜けてるとこない？」って見てあげれば、それで十分機能するんじゃないかなと。 結局のところ、「事前にちゃんと考える」というだけでプロジェクトの精度はかなり上がるし、それがテストファーストの本質なんじゃない？と、この記事を作りながら考えてました。