受け入れテストを構築する方法について、2 つの異なるアプローチを検討しています。サービスレイヤーを呼び出すSilverlightプロジェクトがあります（私は両方を所有しています）。Silverlight の仕様上、Silverlight アセンブリを呼び出すテスト コードは、Silverlight 以外の残りのテストとは別のテスト プロジェクトに配置する必要があります。
1) 思いついたすべての受け入れ基準を取得し、機能ファイルに入れます。シナリオにタグを付けて、シナリオが実行される環境を指定します (@server、@client など)。機能ファイルにも手動テストを含め、@manual タグでラベルを付けます。
長所: BA が作成したすべてのテストを 1 か所にまとめて表示し、場合によっては編集できるようにします。
短所: 一部のシナリオを単体テストまたは統合テストでテストする方が理にかなっている可能性があり、NUnit は SpecFlow よりも優れたツールである可能性があります。
2) すべての受け入れ基準を記述しますが、一部を SpecFlow で自動化し、一部を単体テストで、一部を統合テストで自動化します。SpecFlow で自動化されたシナリオのみが SpecFlow に含まれます。単体テスト、統合テスト、または手動テストを行うシナリオをフィーチャー ファイルに入れることはできますが、これらのシナリオは実際にはコードを実行するものではなく、ドキュメント化の目的でのみ存在します。
長所: 開発者の摩擦とオーバーヘッドが少なくなります。各テストに最適なツールを使用して、さまざまなテストを自動化します。
短所: SpecFlow によって実行されないシナリオを、シナリオを自動化するコードと同期させておく必要があります。
考え？私が考えていない別の方法はありますか？どのようにしますか？