UnitTest と IntegrationTest と Behavior Verification と State Verification

同じ会社の人と、どのテストに力点をおいて時間を割り当てるべきかについて見解が一致したところ別れた所があった。その議論が面白かったのでメモ。
(私の視点で記録してるので、ずれがあるのはごめんね。)

不等号グラフモデルで表現すると
相棒は、
Integration&State > Unit&State >>> Unit&Behavior(Spy or ...)>>>>>>>>>>Unit&Behavior(Mock)

ぼくは、
Integration&State > Unit&State > Unit&Behavior(Spy or Mock or ..)

な感じか。

見解が一致したところは、時間割として、Integration&Stateに力点を入れる方が、良い場合が多い.どうせ入れてポン出してポンをアプリを考えると、DBと返ってくるReturnに対して網を張って、アサーションを、いつかきっちりやる必要がある。それなら、なるべく早いうちから着手すべき。

もっと外枠から考えると、Customer Test網になるんだろう。残念ながら、ここをうまくこなした経験が、まだない。

見解が、別れたのは、Mockの扱い。
相棒は、Mock否定派。
私は、テスト対象をだますMockではなく、私をだますMockに何度か出くわし、あまり信用していないんだけど、それでも完全に捨てきれないものが、Mockにはあると思っている派。

相棒： Mockはデベロッパテストとして、個人が不安解消に使うのは構わないが,あまり当てにしちゃいかん。ありゃ○○ーだよ。限られた時間を割くべきなのは、Integration&State。より本番に近い結合が重要。

私：Integration&Stateに頼りすぎ、テスト件数が増えると、ALLテストでSlow Test問題が出てくる。チームがグリーンを保ってコミットする習慣がなくなるのでは？
相棒：別マシンで、CIでくり返し実行、通知機構があれば、そこは十分カバーできる。
私：フィルターポイやつで void しか返さないオブジェクト、どうすんだ？時間状態に依存するテストは？
相棒：まぁそこは仕方ないか。でも、その場合でも、Mockライブラリに頼らずに、継承でだます（Test Spy／Hand-Coded Test Stub）を好む。

私：設計としてMockは強力なツールになる。1クラスに多くの責務を割り当てがち。そのテスト対象のクラスで本当にテストしたい範囲（責務）を明確に絞って、余計なものをインタフェース切って、呼び出すだけのプログラミングをすることで、すーと責務分配できるのは、Mockのよいところ。

残念ながら、ここは、うまく伝える事はできなかった。

みんなは、 Mockテストを、どう考えてるのかな？

haru01のめも

UnitTest と IntegrationTest と Behavior Verification と State Verification

See Also