@kyanny's blog

To be a cross-functional developer

「あとで捨てることになるコードのテスト」について

同僚とこんな話をした。

例えば「キャンペーンサイトとプレゼント応募フォーム」のような、一時的にしか使わないことがわかっているコードに対するテストをどの程度書けば良いのか?納期は迫っていて、他にもっと優先度の高い仕事もあるとする。最低限 200 が返ってくることだけをテストすれば良いのか、 POST したらどのようなリソースが作られるかまで厳密にテストすべきなのか。

そのとき述べた僕の意見を書いてみる。

追記

同僚の名誉のために補足すると、その時は「不安な部分をテストすべき」という当たり前な結論に落ち着いたのだけど、そもそも詳しく聞いてみたら「僕ならここは不安だから書くと思う」と考える部分については、彼はすでに書き終えていて、その上でさらに厳密にテストを追加すべきだろうか?という問題意識を持っていた、という。なので、以下に意識高そうなことをつらつら書いているけど、同僚氏のほうが僕よりよっぽど意識が高かった、というわけです。

「テストの練習のために書く」という考え方

  • 一時的にしか使わない(あとで捨てることがわかっている)コードに対してもテストを書いたほうが良い(当然)
  • もろもろ優先度との兼ね合いで、最低限のテスト + pending で済ます、というのは現実的だ
  • 一方で、そういうコードはえてしてビジネスロジックもシンプルなので、テストが書きやすい場合が多い
  • であれば、テストを書く練習のためだと考えて、そのようなコードのテストもしっかり書く、というのもアリだと思う

「あとで消すのも最適化の結果消えるのも変わりはない」という考え方

  • コードもテストも、理解しやすさを損ねないならば、よりコンパクトなほうが良い
  • リファクタリングを経てコードやテストが非常にコンパクトになったり、本質的ではない部分をそぎ落としたら不要になって削除する、ということはありえる
  • 最適化を繰り返して極限までコンパクトにした結果、ゼロに収束した、ということ
  • アプリケーションの尺度で考えても同じことが言えて、リファクタリングを経たり仕様が変わったりした結果、あるコードとテストがごっそり不要になった、というのは不自然ではない
  • キャンペーンサイトのように期間限定で使うつもりで書くコードと、十分に最適化されていないまま書くコードは、たまたま不要だと意識するタイミングが違うだけで、結局はあまり変わりはない
  • よって、あとで捨てることになるコードのテストもしっかり書くという意識なり姿勢なり態度なりは、テスト信者的な価値観をわきに置いたとしても、支持されうるもものだと思う

みなさんはどう思いますか?