私はしばらく Web API を作成してきましたが、インフラストラクチャ コード (コントローラー、リクエストなど) に一切触れずに CQRS ハンドラー (Mediatr で管理) をテストできることをうれしく思いました。コントローラーが行うべきことを行っていたため、非常に薄いものでした: リクエストとレスポンスの間で通信します:
[HttpGet("requests")]
public async Task<IEnumerable<AbsenceRequest>> GetAbsenceRequests(GetAbsenceRequests.Query query)
{
return await _mediator.Send(query);
}
しかし、それでも私の Handlers テストがカバーしていないケースがありました。以下にいくつかの例を示します。
- 承認。「間違った」ユーザーが特定のアクションにアクセスしようとしたかどうかをテストできませんでした。彼はアクセス拒否エラーを受け取りました。つまり、特定のアクションの承認属性をテストできませんでした。
- エラー処理。Handler が特定の条件下で特定の例外をスローしたことを確認できましたが、インフラストラクチャ (つまり、例外ミドルウェア) がこの例外を処理する方法を制御できませんでした (つまり、特定の HTTP エラーが発生しました)。
ASP.NET Core により、リクエスト イン レスポンス アウトの統合テストが非常に簡単になり (TestServer のおかげで)、統合テストでこれら 2 つのケースをカバーできます。
私を悩ませているのは、代わりにリクエストを送信してレスポンスをアサートすることによって、ハンドラー テストを維持するか、アクションをテストするかです。
Handler テストが大好きです。かわいくて、はっきりしていて、書きやすいです。リクエスト全体をテストすることははるかに強力ですが、同時に比較的低レベルのアプローチであり、http と json を処理する必要があるため、面倒です。
この選択は非常に紛らわしいので、推奨されるアプローチを知りたいです。