NUnit を使用して TDD を行っていました。私は自分の NUnit テストに行動スタイルで名前を付けていました (given、when、then のように)。ただし、現在、すべての単体テストに MSpec を使用しています。私はまだ最初にテストを書いており、モックなどを使用しています...したがって、それらはまだ単体テストです。しかし、NUnit の必要性はわかりません。
NUnit の学習に費やしたすべての努力を捨てるのは緊張します。BDDはTDDが正しく行われていることを考慮して、TDD/NUnitを完全に放棄する必要がありますか?
BDD を採用したので、"Outside-In" 開発アプローチに従っています。
この開発手法の簡潔な定義は、programmers.stackexchange.comで見つけることができます。私は引用します：
「Outside-In (ロンドン流、トップダウン、または Martin Fowler が呼ぶところの「モックスト TDD」): 対話と共同作業者 (特にトップ レベルの関係者) を前もって知っており、そこ (トップ レベル) から始めて、必要な依存関係をモックします。完成したコンポーネントごとに、以前にモックされた共同作業者に移動し、そこで再び TDD を開始して、実際の実装を作成します (使用されていても、抽象化のおかげで以前は必要ありませんでした)。 ."
BDD を使用する場合は、トップダウン方式で開発し、テストを満たすために依存関係をモックします。BDD テストに合格したら、TDDを使用して、BDD テスト中に発生した依存関係の具体的なバージョンを実装することに戻ります (「インサイドアウト」アプローチを使用)。
したがって、TDD テストと BDD テストはどちらも価値があります。コードのさまざまな側面をテストするためです。つまり、BDD テストでは、ユーザーの操作がシステム内のすべてのレイヤーに対してテストされることが保証されます。一方、TDD テストでは、個々のコンポーネントが詳細にカバーされます。分離（モックによる）。
したがって、NUnit テストを放棄しないでください。
私の答えを締めくくるために、あなたはこう言います：
BDD は正しく行われた TDD です
上で説明したように、BDD と TDD の主な違いは、それらがカバーするコードの範囲です。Dan North は、これに関する優れた記事をここに掲載しています。
私の経験から、NUnit がまだ適切な選択である場合がいくつかあります。たとえば、mspec は現在サンプルをサポートしていませんが、NUnit には TestCase と TestCaseSource があります。これらは単体テストのシナリオで役立つため、xUnit スタイルのツールが引き続き使用される可能性があります。何も「忘れる」必要はありません。ツールベルトのすべてのツールを認識し、目の前のタスクに適したツールを選択することは良いことだと思います.