テスト
Spring の STOMP-over-WebSocket サポートを使用する場合、アプリケーションをテストするには主に 2 つのアプローチがあります。最初のメソッドは、サーバー側のテストを作成して、コントローラーの機能とアノテーション付きのメッセージ処理メソッドを検証することです。2 つ目は、クライアントとサーバーの実行を伴う完全なエンドツーエンドテストを記述することです。
2 つのアプローチは相互に排他的ではありません。それどころか、それぞれが全体的なテスト戦略に位置しています。サーバー側のテストは、より焦点が絞られており、記述と保守が簡単です。一方、エンドツーエンドの統合テストはより完全であり、より多くのテストが行われますが、記述と保守により複雑になります。
サーバー側テストの最も簡単な形式は、コントローラーユニットテストを記述することです。ただし、コントローラーの機能の多くはアノテーションに依存するため、これは十分に有用ではありません。純粋な単体テストでは、単純にテストできません。
理想的には、テスト中のコントローラーは実行時にそのまま呼び出す必要があります。これは、Spring MVC テストフレームワークを使用して HTTP リクエストを処理するコントローラーをテストするアプローチと同様です。つまり、サーブレットコンテナーを実行せずに、アノテーション付きコントローラーを呼び出すために Spring Framework に依存します。Spring MVC テストと同様に、「コンテキストベース」を使用するか、「スタンドアロン」セットアップを使用するかの 2 つの選択肢があります。
Spring TestContext フレームワークの助けを借りて実際の Spring 構成をロードし、テストフィールドとして
clientInboundChannelを挿入し、それを使用してコントローラーメソッドによって処理されるメッセージを送信します。コントローラー（つまり
SimpAnnotationMethodMessageHandler）を呼び出し、コントローラーのメッセージを直接渡すために必要な最小限の Spring フレームワークインフラストラクチャを手動でセットアップします。
これらのセットアップシナリオは両方とも、株式ポートフォリオ [GitHub] (英語) のサンプルアプリケーションのテスト [GitHub] (英語) で実証されています。
2 番目のアプローチは、エンドツーエンドの統合テストを作成することです。そのためには、WebSocket サーバーを組み込みモードで実行し、STOMP フレームを含む WebSocket メッセージを送信する WebSocket クライアントとしてそれに接続する必要があります。株式ポートフォリオ [GitHub] (英語) のサンプルアプリケーションのテスト [GitHub] (英語) では、 Tomcat を組み込み WebSocket サーバーとして使用し、テスト目的で単純な STOMP クライアントを使用することで、このアプローチも示しています。
