私は ASP.NET MVC を使用したビヘイビア駆動開発を学んでおり、 Steve Sandersonの投稿に基づいて、 BDD が少なくとも次のテスト タイプを意味する可能性があることを理解しています: コードの個々のユニットと UI の相互作用。この投稿で同様のことが言及されています。単体テストと統合テストの両方が必要な場合、2 つの異なるテスト フレームワークが必要ですか?
MSpec などのコンテキスト/仕様フレームワークを使用した、リポジトリ、コントローラー、およびサービスの単体テスト。これを使用したテストの結果は、開発チームに役立ちます。
SpecFlow と Watin のように、特定の/when/then フレームワークを使用して、完全な動作 (統合) をテストします。このテストの結果は、私のクライアントに役立ちます。
BDD の使用についてこれまでに見たビデオは、リポジトリやコントローラーなどの動作をテストせずに、エンティティの動作をテストすることに限定されていました。 BDDアプローチ？
個人的には、機能固有のテスト (つまり、「ユーザーが新しい会社のレコードを作成する」) を構築するために SpecFlow を使用します。リポジトリまたはサービス クラスをテストするために、NUnit でユニット/統合テストを使用します。統合テストは、テスト中にデータベースと対話する必要がある場合に使用します。ユニットは、テスト対象のターゲット オブジェクトで外部との対話なしでコードを実行する場合に使用します。
非 UI テストに BDD フレームワークを使用する必要はないと思います。必要に応じてできますが、これに関する厳格な規則はありません。これを行う場合は、テスト用に複数のプロジェクトを作成することを強くお勧めします。すべてのテストを 1 つのプロジェクトにまとめるのではなく、分割しておくことをお勧めします。あなたはそれらに名前を付けることができます：
MyProject.Tests.Features <-- BDD SpecFlow テスト用。
MyProject.Tests.Integration <-- 外部リソース、つまりデータベースにアクセスするテスト用。
MyProject.Tests.Unit
2 つの BDD フレームワークを使用したくない場合でも、BDD の方法で MSTest/NUnit を使用できます。たとえば、このブログ記事では、BDD に近いが MSTest/NUnit 単体テストを対象とした、優れた命名規則について説明しています。リポジトリのようなものをテストするときに、これを SpecFlow 以外のテストに使用できます。
要約すると、テストで SpecFlow と MSpec を使用する必要はありませんが、使用する場合は、別のテスト プロジェクトをお勧めします。
Jason が投稿した内容には概ね同意します。
仕様を、システム/統合テストとユニットレベル テストの 2 つのカテゴリに分けたいと思うかもしれません。どちらのカテゴリも任意のフレームワークで記述できますが、コードのみのアプローチ (NUnit、MSpec など) ではビジネス アナリストが C# を記述できる必要があることに注意してください。仕様書の作成にアナリストやユーザーを関与させたい場合は、SpecFlow/Gherkin の方が優れたアプローチになる可能性があります。構文とルール (Given、When、Then) が理解しやすく、ユーザーの観点から仕様を記述することは、少しトレーニングすれば簡単に書き留めることができるためです。コミュニケーションのギャップを埋め、チームがドメインのユビキタスな言語を形成するのをユーザーに支援してもらうことがすべてです。
「アウトサイド イン」と「インサイド アウト」の両方の作業をサポートする仕様にすることをお勧めします。ユーザー/アナリスト/製品所有者によって書かれた「アウトサイド イン」の SpecFlow 仕様から始めて、「未実装」から「グリーン」に向かって実際のコードを書くことができます。この機能をサポートするコードは、TDD を使用して、MSpec のような技術指向のフレームワーク (「インサイド アウト」部分) を使用して開発されます。
単体テストと統合テストの両方に MSpec を使用するリポジトリは次のとおりです: https://github.com/agross/duplicatefinder。