インターネットには決定的な答えや、質問に答えるのに役立つ一連の原則がないようです。だから私は答えや指針となる考えを見つけるのを助けるためにSOの偉大な人々に目を向けます:)
SpecFlow は .NET の BDD に非常に役立ちます。しかし、BDD について話すとき、単に統合/受け入れテストについて話しているのでしょうか?それとも、TDD の完全な代替である単体テストについても話しているのでしょうか?
私は小規模なプロジェクトでしか使用していませんが、単体テストでも、SpecFlow によってコードのドキュメント化と言語に関する考え方が改善されることがわかりました。逆に言えば、テストの完全なコードを 1 か所で確認することはできません。手順が断片化されているためです。
今あなたに........
編集: 単体テストに BDD スタイルの構文を使用する RSpec が RoR コミュニティにあることを忘れていました。
最近SpecFlow、BDD テストに使い始めましたが、まだ単体テストと統合テストも使用しています。
基本的に、テストを個別のプロジェクトに分割します。
私の単体テストは単一のメソッドをテストするためのものであり、データベース呼び出しや外部参照は一切実行しません。データベースや Web サービスなどの外部リソースと対話する単一のメソッド呼び出し (場合によっては 2 つ) の統合テストを使用します。
私は BDD を使用して、プロジェクトのビジネス/ドメイン要件を模倣するテストを記述します。たとえば、プロジェクトの請求書生成機能の仕様があります。または買い物かごを操作するため。これらのテストは、
ユーザーとしては、
セマンティクスのタイプ。
私のアドバイスは、ニーズに基づいてテストを分割することです。SpecFlow を使用して単体テストを実行しようとしないでください。
与えられた:
したがって：
でも：
したがって：
2 つの異なる適切なサイズのアプリケーションでの BDD テストに specflow を使用しました。文の命名規則のねじれに取り組んだら、かなりうまくいきました。BA と QA、そしてインターンでさえ、アプリケーションの BDD テストを書くことができました。
ただし、単体テストにも使用しました。異端！何人かの悲鳴が聞こえます。しかし、それには非常に正当な理由がありました。このシステムは、さまざまなデータに基づいて多くの計算や決定を行う役割を担っていました。テスト目的でこのすべてのデータを入力する必要がある多くの単体テストでは、specflow によって提供されるテーブル形式を介して、単体テストに使用されるデータの管理が非常に簡単になります。データ リポジトリをテーブル形式で効果的にモックして、さまざまなコンポーネントを精力的にテストできるようにします。
すべてのケースでそれを行うかどうかはわかりませんが、私が使用したケースでは、単体テストを実行するために必要な量のデータを非常に簡単かつ明確にレイアウトすることができました.
これは、TDD プロセスの一部として記述された単体テスト ケースを置き換えるものではないことを意味する統合テストと見なされます。誰かがこれについて異なる意見を持っているでしょう。IMHO単体テストケースはメソッド/関数のみをテストし、すべての依存関係をモックして注入する必要があります。統合テストに関しては、模擬的な依存関係ではなく、実際の依存関係を注入することになります。任意の単体テスト フレームワークで同じ統合テストを実行できますが、BDD は、平易な英語 (またはローカライズされた言語) であるドメイン固有言語で統合テストのユース ケースを説明するより明確な方法を提供します。
タ、
ラジーシュ
最終的には、顧客が望んでいるものを正確に顧客に提供しようとしています。そのため、SpecFlow に加えて単体テストを作成する必要はないと思います。結局、同じコード ベースを実行します。私はかなり新しいですBDD/ATDD/TDDが、「完全」でTDDに厳密に準拠していることを除けば、単体テストをさらに作成する必要はありません。
チームが分散していて、開発者がアプリケーション全体を実行できなかった場合、個別の単体テストが必要になると思いますが、開発者がコードベース全体にアクセスでき、アプリケーションを実行できる場合は、なぜですか?もっとテストを書いてください。