MockMvc とエンドツーエンドのテスト

MockMvc は、spring-test モジュールの Servlet API モック実装に基づいて構築されており、実行中のコンテナーに依存しません。そのため、実際のクライアントとライブサーバーが稼働している完全なエンドツーエンドの統合テストと比較すると、いくつかの違いがあります。

これについて考える最も簡単な方法は、空の MockHttpServletRequest から始めることです。それに追加するものは何でもリクエストはなります。驚くかもしれないのは、デフォルトではコンテキストパスがないことです。jsessionid Cookie なし ; 転送、エラー、非同期ディスパッチなし。実際の JSP レンダリングはありません。代わりに、「転送された」および「リダイレクトされた」URL は MockHttpServletResponse に保存され、期待してアサートできます。

つまり、JSP を使用する場合、リクエストの転送先の JSP ページを検証できますが、HTML はレンダリングされません。つまり、JSP は呼び出されません。ただし、Thymeleaf や Freemarker など、転送に依存しない他のすべてのレンダリングテクノロジーでは、HTML が期待どおりにレスポンス本文にレンダリングされることに注意してください。@ResponseBody メソッドを介して JSON、XML、その他の形式をレンダリングする場合も同様です。

または、Spring Boot と @SpringBootTest の完全なエンドツーエンド統合テストのサポートを検討することもできます。Spring Boot リファレンスガイドを参照してください。

それぞれのアプローチには賛否両論があります。Spring MVC テストで提供されるオプションは、従来の単体テストから完全統合テストまで、さまざまな規模のストップです。確かに、Spring MVC テストのオプションはいずれも、従来の単体テストのカテゴリに分類されませんが、少し近いものです。例: モックサービスをコントローラーに挿入することで Web レイヤーを分離できます。この場合、データアクセスレイヤーをその上のレイヤーから分離してテストする可能性があるため、DispatcherServlet を介してのみ、実際の Spring 構成で Web レイヤーをテストします。また、スタンドアロンセットアップを使用して、一度に 1 つのコントローラーに焦点を合わせ、それを機能させるために必要な構成を手動で提供することもできます。

Spring MVC テストを使用する場合のもう 1 つの重要な違いは、概念的には、そのようなテストはサーバー側であるため、使用されたハンドラー、例外が HandlerExceptionResolver で処理された場合、モデルのコンテンツは何か、バインドエラーは何かを確認できることです。でした、およびその他の詳細。これは、実際の HTTP クライアントを介してサーバーをテストする場合のようにサーバーが不透明なボックスではないため、期待値を記述しやすいことを意味します。一般に、これは従来の単体テストの利点です。記述、推論、デバッグが容易ですが、完全な統合テストの必要性に取って代わるものではありません。同時に、最も重要なチェック項目はレスポンスだということも忘れてはなりません。つまり、同じプロジェクト内であっても、テストの複数のスタイルと戦略のための余地があります。