この本を読んでいてふと思った。開発の品質はテストが決める、と言われるくらいテストは重要なもの。むしろテストがないのはありえないし、関数の単体テストのように、自動化したほうが適切なテストは自動化したほうがいい。そこは間違いないのだけども、テストファーストを常にMUSTにするのはストイックすぎるんじゃないか、と個人的に思う。
テストファーストが向かないタスクもあるのでは
テストファーストをやるためには、まずテスト対象となるクラスなり関数なりがきっちりFIXしている必要がある。だが実際にはそこまでガチガチに最初から要件が固まっているタスクばかりとは限らない。また要件自体の変更や見落としが現場では良く起こる。作っている最中にもっといい実装方法が思いつくこともザラだ。渡す引数が変わることもないではない。そこからさらに具体化されていった何十何百もの関数のテストを変更の都度修正していくとなると、これは相当な工数を必要とする。
いついかなる場合もMUSTにするのは合理的とは限らないのではないか。最終的にプルリクを出すときにテストが書かれていれば妥協していいと個人的に思う。自動テストの作成コストは馬鹿にならない。関数自体よりもテストコードを書くほうが時間がかかるのもよくあることだ。それくらい重いコストがかかるものだから、自らのタスクでテストファーストを適用するべきかは実装者が選べてしかるべきではなかろうか。どのような経緯を辿ったのであれ、マージする際にコードとテストが揃っているなら、それらがどのような順番で書かれたのか気にする必要があるだろうか。
コーディングを楽にする自動テストもある
もちろんコーディングを楽にするテストもある。
どの道動かしてみないとプログラムなどというものはちゃんとできたかどうかわからないものだ。一発書きで動くことももちろんあるが、いつもそうではない。結局、どのような手法であれ、テストは必ずコーディング中も行っているはずだ――書きっぱなしにする怪しからぬ人もいないわけではないのだが:-(
そのテストをXUnitのようなテストツールで行うと、レスポンスが早かったり操作が楽だったりして助かることはよくある。テストを最初に書くというより、同時並行でテストも書くイメージが近い。
テストファーストが楽なこともある
テスト用のリクエストと期待するレスポンスを先に用意しておいて、それと合致するかどうかを見るようなテストであれば、テストファーストが品質と開発効率に資すると思う。とにかくコーディングして自動でテストを回してみて、通ったら少なくとも一部は動いていると考えられる。
是々非々
つまるところケースバイケースである。テストファーストが向いているタスクもあれば今一つ向かないタスクもあり、スケジュールのタイト具合やプログラマーの個性次第のところもあるので、テストファーストに関しては、あまり教条的にならないほうがいいのではないかなあ、と思う。
