私は BDD の経験はありませんが、いくつかの調査の結果、私たちのプロジェクトで非常に役立つことがわかりました。
開発者は単体テスト用に (SpecFlow を使用して) BDD スタイルのテストを作成したいと考えており、テスト チームは自動化された Web UI テスト (Selenium を使用) と Web サービス統合テストを配置する場所が必要です。
問題は、テスターのテストと開発者のテストで同じオブジェクトを共有する方が良いのでしょうか、それとも、これら 2 つの世界を分離することで、たとえばテスト管理が改善されるのでしょうか?
SpecFlow は私たちのテスターにとって完璧なソリューションではないようです (Robot フレームワークまたは Fitnesse が考慮に入れています) が、さまざまな種類のテストを作成するために共通のツールとライブラリを使用することは理にかなっているようです。
ありがとう、
2つのテストシステムが重複しているということは、共有するものが予想よりも少ないことを意味している可能性が高いことがわかると思います。
まず、BDDの下での開発サイクルについて考えてみましょう。新しい機能定義から始めて、それをサポートするいくつかのシナリオとコードを開発します。実際、これを適切に実行している場合、各Specflowシナリオはビジネスレベルのテストであり、その単一のビジネスレベルのテストの開発を推進するために、おそらくいくつかの下位レベルのユニットレベルのテストも開発しているはずです。このプロセスはさまざまなもの（「7ステッププロセス」を含む）として説明されていると聞きましたが、重要なことは、ビジネスレベルに合格するために、複数のRed GreenRefactorユニットテストサイクルを完了するという、サイクル内のサイクルであるということです。ビジネスレベルのシナリオを赤から緑に変えるサイクル。
これまでのところ、特にMVC / MVVMまたは同様に階層化されたコードベースで作業している場合は、UIレイヤーを必ずしもテストしていません。実際、これがクライアントに作業を勧める方法です。クリックしてコマンドが呼び出されるかどうかをテストする必要はありません。作業中のフレームワークのテストに時間を無駄にしたくないと想定しているため、コマンド自体を呼び出すだけです。 。
ただし、Seleniumについて言及しているので、ブラウザーとの対話を促進するためにSeleniumを使用していると想定します。したがって、UIレベルでもテストを実行したいとします。このコードは複数のドメインを横断しており（とにかく誰のドメインであるかを参照）、ログインや一般的なプロセスなど、現在再利用したい高レベルの概念を提供します。このコードはまだ存在しておらず、ブラウザとのやり取りが他のコードと結びついていないためです。
したがって、2つのテストコードベースが作成されることになります。1つは単体テストとビジネスレベルの仕様で使用され、モックと一緒に保持されたコードのチャンクまたはシステム全体の一部です。
Seleniumを組み込んだもう1つは、統合テストとシステムテストのために、完全なシステムとの相互作用をテストします。
SpecFlow仕様を使用すると、システムを説明するための一般的な文法など、いくつかの非常に優れた機能が得られますが、それを使用することにした場合、同じコードにバインドされるとは思いません。