仕事でWebアプリケーションを書きはじめてかれこれ半年経っていろいろ蓄積されたものもあるのでいくらか書いておく。
テスト書きたい && 書こう
アルバイト先ではテストを書かない方針、より正確に言うと「(頻繁に変更される部分でないかぎり) テストは書かなくてもいいよ」という方針で、現状ではRailsが自動生成したテストファイルしかリポジトリにはない。
ぶっちゃけWebアプリケーションのテストは考えることが多すぎて非常にだるいし、僕は悪い人間なのでまだテストを書く習慣がついておらず、「テスト書かなくてもまあいっか〜」で済ましがちなので、それほど異存があるわけでもない。
けど、たとえばあるコントローラのあるアクションでいろいろ複雑な計算をしているんだけど、なんかバグってるっぽい、けどあまりに巨大で (150行くらいある、Webアプリケーションのアクション (メソッド) ひとつが100行越えているなんて、控え目にいっても狂っている) loggerをつかってちょくちょくデータの変遷を見るのもだるい。
そういう巨大なアクションの中で明らかに処理のコンテキストが違うよな、という部分が見受けられて、それらをたとえばService層やApplication層に分離できそうだな、というのもぼんやりと頭に浮かんでくる。
で、そうして分離されるとテストのしやすさが必然的に上がるのだとおもう。そうすればテストを書く気運が高まり、自動化されたテストで人力テストに割く労力や時間が減らせるはず。
僕はすべてのテストを自動化できるとはおもっていない。けど、人力でやる必要のない (= 自動化できる) テストにリソースを割くのはばかばかしいとおもうし、(自動化された) テストを書くコストに見合う結果が得られるのなら積極的にそうすべきだとおもう。
ところで、テストはそれ自体が実装のインターフェースについての宣言とも考えられる。そういった考え方を発展させるとBDD (Behavior Driven Development) などに至るのだろうとおもう。ということは、実装が正しい仕様のもとに書かれているかどうかの判断は、テストコードを読むことで (ある程度は) 判断できるし、仕様に対する理解が正しいかどうかというテストに目を向ける人間の心的負担も減りそう。(仕様に対する誤解がままあったりしたのでこれはかなり重要だとおもうのだ……)
テストコードは問題のすべてを解決しうるものではないけれど、10%か30%か50%か99%か、いくらかは解決、あるいは削減してくれるのではないかとおもう。
自分から率先してテストを書くことで「テストのありがたみ」みたいなのを徐々に周知していきたい。
