GWT コードをテストする最良の方法は何ですか?
ホスト モードの GWTTestCase は遅すぎて、モック フレームワークはどれも機能しません。
現在、http://robvanmaris.jteam.nl/2008/03/09/test-driven-development-for-gwt-ui-code/ で提案されている MVC に従い、GWTMockUtilitiesの disarm() と restore() を使用してモックを作成しています。ウィジェット。そして、GWT MVC で View をテストする方法をまだ見つけていません。GWT コードをテストするより良い方法はありますか?
GWTウィジェットを個別にテストする場合、多くのオプションはありません。GWTTestCaseを使用してウィジェットをインスタンス化し、そのAPIを介してテストできます。これはGoogleがGWTウィジェット自体に対して行うことです。RadioButtonTestのソース
ただし、イベント発生メカニズムはGWTTestCasesでは機能しません。つまり、プログラムでボタンをクリックして、リスナーでonClick（）コールバックメソッドが呼び出されることを期待することはできません。また、基盤となるDOMを取得することは不可能ではないにしても難しいため、低レベルのHTML送信コードをテストするための最良のツールではない可能性があります。
正しい手順をすべて実行しているようです。Robの記事は、Model-View-Presenter（MVP）デザインパターンを使用してテスト可能なコードを作成する方法についての優れた説明を提供します。ビューレイヤーから除外するロジックが多いほど、優れています。それが不可能な場合は、Seleniumなどのツールを使用して、動的UI動作の焦点を絞ったテストを作成します。
私は同様の戦略に従いました-ウィジェットに最小限のコードを使用したMVP。いくつかのケースでは、Gridクラスをラップするコードを記述したので、GWTTestCaseでコンポーネントをインスタンス化し、グリッドを渡し、コンポーネントでいくつかのメソッドを呼び出し、グリッドの状態を確認することができました。Test-FirstGWTに関するBetterSoftwareの記事を書きました。これは、私のブログで読むことができます。
UI以外のGWTクラス（URLエンコードやディクショナリなど）を使用するコードをテストする場合は、GWTTestCaseを使用するか、コードが単純すぎて解読できないまで同様のラッピング戦略に従う必要があります。次に、Seleniumのようなツール、またはライブラリを正しく使用していることだけをテストするいくつかのターゲットGWTTestCaseとの統合テストを使用します。これは、JBRainsbergerが「フレームワークをテストしないでください」と述べています。
別の方法として、 gwt -test-utilsを試す必要があります。これは、スタンドアロン JVM で GWT クライアント コードを実行し、必要なもの (コンポーネント、RPC サービスなど) をモックする機能を提供します。
私のために働いたもの：
従来のモデル/ビュー/コントローラーを使用します (たとえば、ビューまたはコントローラーにビジネス ロジックはありません。コントローラーはビュー イベントをモデルのメソッド呼び出しに変換するだけです)。
モデルとコントローラーのコードを、GWT ビュー ウィジェットや、GWT に依存し、プレーンな古い JVM ではインスタンス化できないその他のクラスから分離します。その後、古き良き JUnit でテストできます。
モデルとコントローラーがビューに正しく接続されていることを確認するために、GUI を介してシステムをテストするためのエンドツーエンドのテストを作成します。GWTTestCase を使用するよりも、アプリをデプロイして起動し、WebDriver を使用して JUnit から制御されたブラウザーを介して操作する方が高速であることがわかりました。
JMock を使用して、http ://www.jmock.org/gwt.html のような非同期呼び出しをテストします。