Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey

Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので読み返してみました。

Testing like the TSA by David of 37signals（TSAはTSAロックのTSAですね。RailsConf行く時に買った）

予想通り、DHHはなんでもかんでもテストを書くということに対してはだいぶ批判的なスタンス。

曰く、テストを書くということの裏側には、テストを書く時間、テストをアップデートする時間、テストコードを読んで理解する時間といったコストが発生しているので、テストを書くことによって得られるメリット（回避できる問題）とのバランスをよく考える必要がある、と。

議論を呼ぶことは承知のうえでDHHが提案する「Railsアプリのテストにおいて、やってはいけない7つのこと」は以下の通り。

100%のカバレッジは目指さない
コードとテストの比率は1:2だとコード・スメルがしてくる。1:3だと酷い匂い(stink)（訳注：要は、テストコードがテスト対象コードの倍を超えないくらいにしましょう、ということだと思う）
作業時間の1/3以上がテストに関する作業にかかっているとしたら、何かやり方を間違えている。半分以上をテストに割いているとしたら完全に間違っている
ActiveRecordに標準で用意されているアソシエーション、バリデーション、スコープについてはテストしない
異なる要素を結合することから起きる問題について結合テストを使う（単体テストで間に合うものには用いない）
プログラマ以外の人がテストを書いてくれるような魔法の国に住んでいるのでもないかぎりCucumberを使わないこと（そこに住んでいるのなら、妖精の粉の入ったボトルを僕に送ってくれ！）
すべてのコントローラー、モデル、ビューについてテストファーストでやろうとしないこと（DHHの場合はだいたい20%がテストファースト、80%がテストアフター）