例えば、DBに格納されているデータを引っ張り出して
ゴニョゴニョ計算する処理があったとします。
さて、皆さんはこの処理の単体テストを書くとしたら
どうしますか？
DBアクセス部分と計算部分を1つのロジックと見なし、
一気にテストしちゃいます？
確かに、処理のユースケースとしてはそのテストコードは
正しいのかもしれません。
ですが、やろうとしているのは「単体テスト」です。
私だったら、
- DBアクセス部分
- 計算処理
の2つにメソッド(or クラス)を分けて、
それぞれに対してテストコードを書きます。
で、
- それらを呼び出す(結合する)処理
も別途用意しておいて、
それのテストの確認としては「呼べていれば良い」レベル*1。
単体テストって、
- こうしたらこうなるべき
の組み合わせに留めるべきで
- こうして、次にこうして、そしたらこうなるべき
になった途端にテストの前提条件も増えて
確認点が増えてしまいます。この辺はユースケースに絡むところでもあるので
時間かけて単体テストでテストコード書いてまですることかな、と思うのです。
DBアクセス部分、計算部分それぞれが思うとおりに動作するという
小さな機能の動作確認の積み重ねが
早くテストを実行できるからフィードバックを受けやすい。
計算部分のテストをしたいのに、DBに格納するデータを考えるのって、
何か違う気がしません？
部分最適の集まりでトータルで「良い品質」は担保できないのは理解しているけど
かといって、単体テストに根本的な解決を求めてもしょうがないと思うんです。
単体テストきちんとやってるから結合テストいらないですよ、とはならないでしょう？
足元固めて、確実に進めた方が良い結果に繋がりやすい気がするんです。
*1:極端かもしれないけど、テストしなくてもいいかも。だって以降のテストフェーズで確認するでしょ？
