ひがさんの意見！さすが！目から鱗の提案だ！
ひがやすを blog ■極力ユニットテストを書かずに品質を確保する方法
やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。
ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。
これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。
http://d.hatena.ne.jp/higayasuo/20080423/1208922541
テストより先にコーディングとユーザーテストを先に行うという考えかた。
テスト駆動開発以前に戻ってしまうという懸念もなくはないけど、
時代は繰り返しているようで経験値は貯まってるから、大丈夫かな。
コーディング能力の高いメンバーが揃っている場合、この方法は特に有効かな。
僕らの会社のようにコーディング力が弱いプログラマーも多いチームの場合にも、
この考え方を応用できないかと考えてみようと思う。
ユーザーテストに耐えうる品質のコーディングは最低でも必要ということか。。。
僕は、テストファーストのメリットに
「仕様の確認」と「リファクタリング」もあげているけど、
このあたりもちゃんと拾いたい。
思いつきだけど、
コーディングしながら、テストポイントになる部分だけをアノテーションでマーキングして行くのはどうだろう？
テストコードは後で作るとしても、ポイントのチェックはコーディング時が一番精度が高いと思うので！
時間があったら、もっと考察してみよう。
