テストコードを先に書くことは、一部のエンジニアにとって可能でも、
プロジェクトチーム全体で徹底させることは難しい。
テストコードは、本質的なアプリケーションのプログラミングに比べて難易度が低いわけではない上、とても煩雑だ。
また、プロジェクトチームの実装者のレベルによっては、テストコードのレベルもまちまちになる。
適切な「テスト設計」を行った上で作成するテストコードでなければ
すぐさま意味を成さないテストコードとなる。またテストケースの網羅率もばらばらとなるだろう。
テストコードの再利用性は、設計されてこそ得られると考えてる。
確かにテストコードを書いていれば、メリットは得られる。
・リファクタリングというプロセスの採用
・再帰テストの効率化
ここまでしてテストコードを書く必要性のある部分もある、例えばフレームワークコードが代表的だ。
しかし、業務アプリケーションの業務ロジックで、
そこまでしてテストコードを書く必要性はあるのか？と、やはり疑問に思うことが多い。
工数は確実に増加する。再帰的なテストを目論んでいるなら、なおさらである。
またデータベース関連のテストや、プレゼンテーション関連のテストは、自動化が難しい。
テストコードのテストはどうするのか？なども課題だ。
そもそも、テストの完全自動化という考え方は、ほとんど現実的でもない。
→つまり、自動化に適さないテストは必ず存在する。
その話は、ちょっと置いておこう。
さて、今参画しているプロジェクトでは、テストコードを書かない方針で進めている。
しかし、別の方向でTDDの考え方を取り入れている。
それは「テストケースファースト」だ。
実装者がテストケースを「実装よりも先」に記述する。
（テストコードは書かない。）
テストケースを先に書くことで仕様からロジックを検討することを可能とし、
仕様理解を促進する。そのため実装する前の早い段階で、
仕様の誤解などを顕在化することが可能となる。
また、イレギュラーケースを明確にすることで、
設計漏れなどを実装前に見つけることもできるだろう。
これにより、詳細設計というフェイズを飛ばしてしまうことも考えている。
テストコードファーストは、難しいプラクティスだが
テストケースファーストならば、どこのプロジェクトでも容易に取り入れられて、
テストファーストの多くのメリットを享受できると思う。
今回のプロジェクトでそれを検証してみようと思う。
