テストファーストという用語は認知されつつあるが
XP(eXtreme Programming)においてテストファーストが脚光を集め、またTDD(Test Driven Development)においてそれに拍車がかかってきています。一方、旧来のウォーターフォール的開発(Winston W.Royce氏の1970年のIEEEの記事ではなく、米国防省規格DOD-STD-2167における手戻りを許さない1回こっきりの開発プロセス)やV字モデルでも、コーディング後にモジュールレベルのテストを実施します（実際はモジュールレベルのテストは省略してしまっている組織が多そうだが）。
では実際に、ユニットテストではどのようなテストを実施すればよいのか？になるとあまり語られている記事や本を目にすることがありません。テスト技法を羅列したような本はあっても、これはプログラミング言語の文法を羅列した本と同様実践的な作業には役立ちません。
ユニットテストにおいて、ホワイトボックステスト技法による制御パステスト（カバレッジ）やデータフローテストなどを設けるべきなのでしょうか？ それともブラックボックステスト技法の同値分割・境界値分析からでよいのでしょうか？
また、開発者はこれらテスト技法をどこまで知っているべきでしょうか？
テスト技法やテスト設計を知らないと
XPもソフトウェアエンジニアリングを押さえていないカウボーイ・プログラマにかかれば、無秩序でいきあたりばったり開発に取って代わられてしまいそうです。
プロジェクト内で、どのレベルのテストにどこまでの深さのテストを盛り込むかを計画することはとても大切なのですが、いかんせん経験が少なく技法も知らないと計画が立ちません。テストの本を読んでも「難しすぎ」て・・・となります。
TDDと単体テストの違い
【連載◎開発現場から時代を眺める by arton】第2回 | 日経 xTECH（クロステック）
この記事に、TDDと単体テストの違いについて言及されている個所があります。
単体テストはどうやらトランザクション単位のテストのことを指しているようで、ユニットテスト（クラス単位）より粒度が高いものを指している点少々気になりますが、テストとしては異なる観点のものだと述べている点には賛同できます。TDDだと異常系や複合した状況のテストに弱い傾向があると思います。機能を実現する方向でのテストと、バグがないかしらみつぶし的に（作業効率があるので全数テストではないですが）テストする観点との違いが両テストの間にあります。
