Stubだらけの単体テストはもう嫌だ

今日の話題は、単体テストコードの書き方というか、書式というか。

毎日、実際のコードを書く時間よりも単体テストコードを書く時間が長くて
ずっとイライラしていました。

うちのイギリスの職場は、単体テストをやる環境はかなり揃っているほうだと思う。
有識者もいる。
単体テストを書ける人が多数派。
きちんとクラス間もInterfaceを挟んで分離可能な構造が基本的には保たれています。

// Arrange
...

// Act
...

// Assert
...


というように、設定部分と、実行部分と、期待結果部分とを
きちんと分けて書いているのでかなり見やすい部類ではあると思います。

だけど、まだ見にくい。

私は手動の単体テスト時代を知っている人なので、
あの手っ取り早い時代は良かったな、なんていまだに思ったりもする。

なにより、要項書が人が読めるように書いてあるのが良かった。
まぁEXCELに記述してあるんだから、読めない方がおかしい。
でも、今はテストコードがその役割を担っている。
が、担い切れていない。

はっきり言って、今のテストコードでは、
Arrangeの所を見ても何のテストしているのか中々ピンと来ないんですよ。
テストメソッド名で補足されるものの、やっぱりわかりません。

変更の結果Failになってメンテナンスしなければならない場合なんて
Arrangeがぐちゃぐちゃなテスト見た瞬間卒倒しそうになります。
ゆえに、
Arrangeの所にStubの期待値がいっぱい書いてあるのは悪だと思います。

Arrangeの所は、EXCELで要項書を書いていたときのように、
条件の羅列のみにするべきだ。


Stubは全て、PrivateのSetUpメソッドの中にカプセル化しましょう。
そうすれば、単体テストがテスト要項書のように読める。

カプセル化部分は多少頑張らないといけないけれど。
だけどですよ、こうすれば
人間の集中力をうまく分割化できます。

一つは、テストケースを考える部分。
もう一つは、Stubなどを定義する部分。

テストケースを見ながら、Stub定義の正しさなんて見ていた日には、
テストコードの品質なんて保てるわけがありません。
人間様の脳はそこまですばらしくできていない。

「Stubの定義がテストケースの条件だ、だからArrangeに書くべきだ」
という人がいるかもしれませんが、
その場合は、Stubの振る舞いを
人間のわかる言葉で、SetUpメソッドに指定できるようにしましょう。
「Aが来たらBを返す」というStubをArrangeに書くのではなく、
String引数で"A->B"などを指定できるようにしましょう。

だって、EXCELの要項書は、そのレベルで
エッセンスを抜粋して要項書にしていたでしょう！？

この方が観点レビューの工数は驚くほどやりやすく、
質もあがるはずです。

と心で叫ぶだけではおもしろくないので、
今日自分の考えをテストコードで表してみました。
思ったより時間を食ってしまった部分もあるのですが、
レビュアーの反応が気になるところです。

結果についてはまた後日。