元々は TDD Advent Calendar jp: 2012 : ATND で人数が足らなかった時の予備として用意していたのですが、めでたく人数が埋まったため単発で上げてみます。
僕は自他共に認めるTDDマニアですが*1、敢えてテストを書かないことの重要性について説きたいと思います。
id:shuji_w6e さんの 軽量なテスト駆動開発を目指して #TddAdventJp - やさしいデスマーチ と近いですが、shuji_w6eさんのがテストを軽くするのに対しこっちはそもそもテストを書かないようにするということです。
テストを書かなくてもいい(書く必要のない)ケース
寿命の短いプログラム
TDDというのは最初にテストを書くコストというのがどうしても発生するため、寿命の短いプログラムだとTDDの恩恵を受けづらいです。
自分の経験上、半年以上メンテする必要があるプログラムだと保守フェーズでTDDの真価が発揮されていると感じます。(機能追加やバグ修正などでプログラムが改修されたとしても、既存のテストが全部グリーンであればデグレがないことは担保されているため)
逆に使い捨てであることが分かっている一時的なプログラム(ワンライナーのスクリプトや、期間限定のイベントのためのプログラム)であるならテストコードは書かなくてもいいと思います。
「No Test, No Future (使い捨てのコードだからテストを書かない)」
ただ、当初の思惑から外れてずっと使い続けられることもあるため、その時は責任をもってちゃんとテストを書きましょう。
使い回されることが分かってるなら最初からテスト書けよというツッコミもあると思いますが、僕だったら直近で必要に迫られていないのであればYAGNIの原則*2に則って書かないです。
プロトタイピング
これもさっきのと近いか。
開発前の要件を固めるためのモックとかはテストする必要はないと思います。
本格的な実装時はプロトタイピングで作ったものは一度破棄するはずなので、その時にちゃんとテストを書けばいいかと。
デザイン
- 人間の目で見ないと分からない
- 文字の位置が若干ずれているなんて機械には判断不能
- 頻繁に仕様が変わる
jsでDOMを動的生成するようなケースも含めていいと思います。(この辺は人によって判断は分かれますが)
政治的な理由により
テストを書くスピードよりもリリース時期を優先するとかかな?
ただしこの場合、後から技術的負債を返済するためにテストを書くことを忘れてはダメです。
自分だけしかメンテしないプログラム
テストなくて苦しむのは自分だけですからNE!
ただし半年前のソースは他人のソースと大して変わらなくなるので、半年以上メンテすることが事前に分かってる場合はテストを書いた方がいいです
まとめ
これらの合理的な理由があるならば、敢えてテストを書かないという選択肢をとってもいいのではないかと思います。
プログラマの三大美徳の1つに「怠惰」があるし、テストを書かずに済むのであればそれに越したことはないかと。(もちろん、面倒くさいからテストを書きたくないというのはダメですw)