TDDとテストファースト => TDDのオレオレ定義と5回リロードルール
自分でももやもやしてるのでツッコミ希望。
考えだした元記事 : http://techon.nikkeibp.co.jp/article/TOPCOL/20070806/137518/
TDDを紹介するときに、﹁TDDではプロダクトコードの前にテストを書く﹂という紹介のされかたが多いんですが、これはちょっと誤解を招く表現だなぁ、と思います。TDDを達成するための1つの(とても有効な)技法としてテストファーストがあるわけですが、その関係は"=="じゃなくて包含だよなぁ、と思うのです。
TDDは字義通りに解釈してもしなくても、テストが開発を駆動することが重要なわけです。駆動するというのはもちろん先にテストを書けば駆動してるんですけど、それは必要条件じゃない。
別にあとから作っても*1、
●自分が作ってるモジュールを使ってみたら、APIが﹁ねーよwww﹂くらい使いづらいものであると気づいたり、とか
●テストがやり辛いからこういう設計はやめよう、と判断することとか、
●viewの単体テストを書いてるうちにsetupで詰め込む変数が増えすぎてコントローラが余計な仕事しすぎてることに気づいたりとか
●機能拡張とかリファクタリングをしよう、と思えるのは実行可能なテストという安全網があるからだよね、とか。
そういうのを含めてテストがあるおかげで、開発が楽に/安心してできるようになるわけで、その安心感がTDDの良いところだよね、と。
何を言いたいかというと、TDDとテストファーストを同一のように書くと﹁テストを先に書くとかめんどくせー﹂という層が、上記のおいしさに気づけないんじゃないかな、と。それはもったいないよね、と思うわけです。
いつもいつもテストを先に書くというのがめんどくさくてTDDできない、という人はテストファーストにとらわれず、まずは自分のコードを書いたあとに、5回ブラウザをリロードしたら自動化されたテストを書いてみる、くらいの緩いさで試してみてもいいんじゃないでしょうか。
