同僚とこんな話をした。
例えば「キャンペーンサイトとプレゼント応募フォーム」のような、一時的にしか使わないことがわかっているコードに対するテストをどの程度書けば良いのか？納期は迫っていて、他にもっと優先度の高い仕事もあるとする。最低限 200 が返ってくることだけをテストすれば良いのか、 POST したらどのようなリソースが作られるかまで厳密にテストすべきなのか。
そのとき述べた僕の意見を書いてみる。
追記
同僚の名誉のために補足すると、その時は「不安な部分をテストすべき」という当たり前な結論に落ち着いたのだけど、そもそも詳しく聞いてみたら「僕ならここは不安だから書くと思う」と考える部分については、彼はすでに書き終えていて、その上でさらに厳密にテストを追加すべきだろうか？という問題意識を持っていた、という。なので、以下に意識高そうなことをつらつら書いているけど、同僚氏のほうが僕よりよっぽど意識が高かった、というわけです。
「テストの練習のために書く」という考え方
- 一時的にしか使わない（あとで捨てることがわかっている）コードに対してもテストを書いたほうが良い（当然）
- もろもろ優先度との兼ね合いで、最低限のテスト + pending で済ます、というのは現実的だ
- 一方で、そういうコードはえてしてビジネスロジックもシンプルなので、テストが書きやすい場合が多い
- であれば、テストを書く練習のためだと考えて、そのようなコードのテストもしっかり書く、というのもアリだと思う
「あとで消すのも最適化の結果消えるのも変わりはない」という考え方
- コードもテストも、理解しやすさを損ねないならば、よりコンパクトなほうが良い
- リファクタリングを経てコードやテストが非常にコンパクトになったり、本質的ではない部分をそぎ落としたら不要になって削除する、ということはありえる
- 最適化を繰り返して極限までコンパクトにした結果、ゼロに収束した、ということ
- アプリケーションの尺度で考えても同じことが言えて、リファクタリングを経たり仕様が変わったりした結果、あるコードとテストがごっそり不要になった、というのは不自然ではない
- キャンペーンサイトのように期間限定で使うつもりで書くコードと、十分に最適化されていないまま書くコードは、たまたま不要だと意識するタイミングが違うだけで、結局はあまり変わりはない
- よって、あとで捨てることになるコードのテストもしっかり書くという意識なり姿勢なり態度なりは、テスト信者的な価値観をわきに置いたとしても、支持されうるもものだと思う
みなさんはどう思いますか？
