ネタ元：
シャノンさんとこのてすとふぁーすと http://blogs.wankuma.com/shannon/archive/2007/07/26/87133.aspx
επιστημηさんとこのてすとせかんど http://blogs.wankuma.com/episteme/archive/2007/07/26/87160.aspx
囚人さんとこのてすとさーど http://blogs.wankuma.com/shuujin/archive/2007/07/26/87171.aspx
一番最初に言うと私はテストファーストやテスト駆動開発を推進しているワケではありませんが、ちょっと気になる記述があるのでちょっと誤解を恐れず(^^; 順番に質問させていただきます(^^;
まず、επιστημηさん
・って釘刺しとけば誰だってテストにパスするよう注意してコード書くやん。
それって、仕様書に書いているから、バグは出ないってことですか？
・コーディングの最中に脳内テストやってるってことやん。
・だからちょっとずつ書いてはテストってやんなくても実装終了時点でえぇやん。
んー、つまりは設計せずにいきあたりばったりで書いても脳内でテストしているから大丈夫ということでしょうか？
・何をテストするかをあらかじめ決めておけばそれだけでバグの抑制効果は十分発揮されるやん。
でも、それをプログラムで書けば、そのテストが何度でも簡単に実行できますよね？
次に中さん
・テストコードを先に書くじゃなくってテストケースを先に書くでしょう？
でも実装がすべてあほぼんでもかける実装int add(x,y)とかならまだしも、実体はそうじゃないでしょ？
分割もするでしょ？
それって行き当たりばったりで仕様を決めていい理由にはならないですよね？
それが故に、その場所で何が実現されるべきことなのかを明確にしておく必要があるんじゃないでしょうか？
自分でも気がついていない明確になっていないことがテストを先に実際に作ることで明確になることもあるように思いますが・・・。
・それにプログラム設計書しかもメソッド単位なんて書いたことないし、かけないし、非現実的ですよ。
メソッド単位に書く必要はないと思いますよ。
むしろ実現できないといけない機能について、その仕様がきちんと記述されているか、つまり漏れが確認できるように思いますが・・・。
おまけに何度もテストできるからデグレもすぐ気がつきますし・・・。
それにテストコードは1テスト100行もざらですが、テスト仕様書は1行くらいで俯瞰できる。
ブレークダウンしていけばいいならば、リュウドとしてコードとテストコードは同じになるはず
じゃ実装は不安定なものだから先にやってリスクをつぶしてからテストすりゃいいんです。
テストの前提が崩れるなんてことざらでしょ
それって仕様なんてちゃんと決められないってことなんでしょうか？(^^;
それにクラス実装がなくてコンパイルエラーになることの確認なんておいらはいやだ。
好きか嫌いかはともかくとして、テストはやらないといけないものなんだって認識はあるワケですよね？
方法としてプログラムでそれをするのがイヤだってことですよね？
プログラムで組むメリットはご理解した上でってことですよね？
そのメリットと手間がトレードオフにならないってことでしょうか？(^^;
で、次に囚人さん
・「テストドリブンによりコードは全部自動テストが可能。従って、いつでもリファクタリングできる」という事を免罪符にして、汚いコードを生産する。
この時点でテスト駆動ではないんですけどね(^^;
いつでも出来るではなく、書いた後にすぐにリファクタリングするのがテスト駆動でそれが出来てない時点でそれはテスト駆動開発ではないんですけどね(^^;
単にコードでテスト書いてるだけですね(^^; それは。
・「テストコードがあるからコードレビューは必要ない」というトンデモ理論を持ち出して、コードレビューを省いてしまう。
コードレビューが必要ないとは言いませんが、テスト駆動開発したからコードレビューが必要ないというのは確かに間違いですね。 ただ、これはテスト駆動開発とは別問題ですね。 必要ない理由にはならないと思います。
・テストコードはテストできない。
テスト駆動開発ではまずテストをテストするとあります。 なのでこの認識は間違いだと思いますよ(^^;
・そして、テストファーストの最も大きなデメリット。それは「ぶっちゃけ、しんどすぎる」。
んー、プロジェクトの規模などにもよりますが、慣れるとそうでもないと思うんですけどね(^^;
こう、否定される方のいろんな意見を聞いても、こう「そうだな」と納得ができないんですよね(^^;
すんません、ややこしいこと書いて(^^;