非テストファースト

プロダクトコードに手を加えたければ、まず失敗するテストを書かなくてはならない。このテストファーストの教えは、テストコードとプロダクトコードを同期させていくとても合理的な方法だ。なんだけど、たとえば初めての人には敷居が高いとか、難しさもある。

かといって、なんでもありなのもどうか、と思っていた。ある開発支援ツールは、ソースコードを解析してユニットテストコードを生成してくれるのだそうだ。テストコードを書くコストがネックだから、それを解消します、ですって。初めてそれを知ったとき、いくらなんでもそれは違うんじゃないかと思った。テストコードを書くのにそんなにコストがかかることを問題だと思うところに意味があるんだよ！

テストコードはプロダクトコードと同じだけ重要なんだから、書く手間を惜しんでは何も始まらないという思いは今も変わらない。だけど、テストファーストでなくてもいいんじゃないか、というように、今は考えが変わってきた。

今、異なるアーキテクチャのプラットフォームへプログラムを移植するプロジェクトに参加している。そこで、移植先環境向けに変換したコードに対して、とにかくその時点での動作を全肯定するテストを書いた。イベントに対する状態遷移を記述したものだ。動かしながら、動いたとおりのことを、assertで書いていく。プロジェクトには移植元のコードの動作をよく理解している人がいるので、その人にテストをみてもらう。このイベントに対してこの状態遷移はオカシイ、といった指摘が貰える。そこで、指摘されたようにテストを修正し、テストにパスするようにコードを直す...

これが教科書的なテストファーストでないことは分っているし、テスト駆動と言えるのかどうかよく分からない。しかし、テストの存在がプロダクトコードの振る舞いの記述となり、それによって振る舞いが見える化され、気づきを得ることができ、フィードバックを行うことができた。テストコードとプロダクトコードの二人三脚が回り始めている。始めにテストファーストを説明したときにはピンときていなかった同僚たちも、今やテストコードを書き始めている。全てのテストがパスする状態を保つことの価値を理解してくれている。いい感じじゃないかと思っている。