読者です 読者をやめる 読者になる 読者になる

こと単体テストに至っては部分最適を求めていいと思う

例えば、DBに格納されているデータを引っ張り出して
ゴニョゴニョ計算する処理があったとします。


さて、皆さんはこの処理の単体テストを書くとしたら
どうしますか?


DBアクセス部分と計算部分を1つのロジックと見なし、
一気にテストしちゃいます?


確かに、処理のユースケースとしてはそのテストコードは
正しいのかもしれません。


ですが、やろうとしているのは「単体テスト」です。


私だったら、

  • DBアクセス部分
  • 計算処理

の2つにメソッド(or クラス)を分けて、
それぞれに対してテストコードを書きます。
で、

  • それらを呼び出す(結合する)処理

も別途用意しておいて、
それのテストの確認としては「呼べていれば良い」レベル*1


単体テストって、

  • こうしたらこうなるべき

の組み合わせに留めるべきで

  • こうして、次にこうして、そしたらこうなるべき

になった途端にテストの前提条件も増えて
確認点が増えてしまいます。この辺はユースケースに絡むところでもあるので
時間かけて単体テストでテストコード書いてまですることかな、と思うのです。


DBアクセス部分、計算部分それぞれが思うとおりに動作するという
小さな機能の動作確認の積み重ねが
早くテストを実行できるからフィードバックを受けやすい。
計算部分のテストをしたいのに、DBに格納するデータを考えるのって、
何か違う気がしません?


部分最適の集まりでトータルで「良い品質」は担保できないのは理解しているけど
かといって、単体テストに根本的な解決を求めてもしょうがないと思うんです。
単体テストきちんとやってるから結合テストいらないですよ、とはならないでしょう?


足元固めて、確実に進めた方が良い結果に繋がりやすい気がするんです。

*1:極端かもしれないけど、テストしなくてもいいかも。だって以降のテストフェーズで確認するでしょ?