初めから厳密すぎるテストを書くのは筋悪なのではないかという話

これは人それぞれのコードの書き方に依存するので必ずしも筋悪というわけではない。むしろそういう風に書いてしまえる人もいるだろう、くらいの話。

何が言いたいかというと、自分の場合、ある程度は頭の中でまとめつつとりあえず手を動かして書いてみる→気に入らなかったり、後から「これではあかん」と思ったらインタフェース変える、みたいなことを繰り返しながら、要は同時にリファクタリングしながらコードを書いていくので、初めから厳密すぎるテストを書いてしまうと手戻りが多くなって非効率的なのである。

例えば、とあるJavaScriptのメソッドの返り値がこんな感じだったとしねえ。

{
   valid: true,
   foo: 10,
   bar: 0
}

で、"valid"の部分はほぼ間違いなくこれで行くけど、"foo"と"bar"の部分は後から無くすかもしれない。あるいはkey名を変えるかもしれない。あるいは何か別のkeyを追加したくなるかもしれない。さらに一段下げて、{ valid: true, baz: { foo: 10, bar: 0 } } みたいな入れ子にするかもしれない。

初めから「これで間違いない！」っていうコード設計が出来るなら、上記のようなことを気にする必要はない。が、僕には残念ながらそのような能力はないので、とりあえずは以下のようなテストで済ませておき

assert.match(returnValue, { valid: true });

推敲して、インタフェースが確定した時点で以下のようなテストに変更したい。

assert.same(returnValue, { valid: true, foo: 10, bar: 0 });

初めから↑のようなtestを書いてしまうと、色々変えたくなった時にtestの修正に無駄な時間がかかってしまうので、少なくとも途中まではアソビを持たせたtestにしておきたい。

なので、データ構造に対して部分的なマッチが出来ないテストフレームワークはしんどい。それで構わない人にはいいのかもしれないが、僕のような書き方をする人間にとっては使いづらい。

上記の例では徐々に厳密なテストに移行していくことを想定して書いているが、どの側面における正当性をどのレイヤでどの程度の労力を費やして担保するか、っていう観点なしに「とにかくテストの数が多く、厳密であればあるほどよい」という物の見方にはやっぱり賛同できないなー、と思う昨今。

はじめて学ぶソフトウェアのテスト技法