私は3つのレイヤーで構成されるプロジェクトに取り組んでいます：プレゼンテーション（asp.net mvc）->ビジネスロジック->リポジトリ
3つの部分すべてをユニットテストでテストします。
統合テストを追加する予定です。現在、どの部分をテストするかを決定しています。
次の解決策を検討します。
コアのユーザーが少ない場合は、2番目のソリューションから利益が得られます。たとえば、サイト、モバイルバージョン、コマンドツール。この場合、すべてのクライアントは十分にテストされたビジネスロジックを使用します。
どのソリューションが優れていると思いますか？統合テストを使用した経験について説明してください。
ありがとう。
business logic -> repository:統合テストが必要であり、多くの重大なバグがここで見つかります。多くのパフォーマンス関連のバグも、このレイヤーで不正な SQL クエリを特定することによって発見されます。
presentation:コントローラーのテストに対する反応はさまざまです。Web ページの手動または自動テスト (コード化された UI による) が必要だと思いますが、UI テストはすべてのコントローラーとビジネス ロジックをカバーしていない可能性があります。そのため、現在、コントローラーのテストも作成しています。コントローラーのテストを行うもう 1 つの理由は、CodedUI の自動テストまたは UI の手動テストの実行に時間がかかることです。
インターフェイス統合テストを作成することから始め、次にコントローラー テストを作成し、次にコード化された UI を作成します。 手動テストは、このすべてのアクティビティと並行して行う必要があります。
あなたの最初の選択肢は好みであるべきだと思います。複数のレイヤーにまたがるインプロセス (つまり、ブラウザー自動化ではない) テストを作成する場合は、「外側」から始めて、できるだけ多くのレイヤーを簡単に実行することもできます。コントローラーを呼び出してテストを開始すると、(たとえば、予期しない、または不完全なユーザー入力があった場合に) システムがどのように動作するかについての洞察と安心感が得られます。アクションによって返されたビュー モデルでアサーションを実行して、テストの関連性とカバレッジを最大化することもできます。