The new E2eGWTTestCase enables application developers to write end-to-end tests in a way that is similar to GWTTestCase, instead of relying on tools written for JS, e.g. Selenium or WebDriver. Why is GWTTestCase insufficient for end-to-end testing? The main reasons are: a) GWTTestCase does not support arbitrary server (there is no -noserver option for GWTTestCase). While this does not affect unit tests which do not rely on real servers, this is a show-stopper for end-to-end tests. b) GWTTestCase does not load entry points defined in the module under test. It only loads the GWTRunner entry point that is inserted programmatically. (This might be a result of a, for application entry points often communicate to server to initialize UI.) The net result is, GWTTestCase is limited to unit tests, where the UI components are constructed and disposed of within test code. It cannot be used to test the application as a whole. The current solution for end-to-end testing is traditional Web testing tools that depends heavily on JS, such as Selenium or WebDriver. I consider them second-class solution as they do not operate on the first-class objects of GWT applications, i.e. objects that are available in Java domain. Test code using these tools is subject to many limitations. The most evident problem is xpath, though DebugId mitigates it to some extent. Other problems include the breakage of refactoring, and cumbersome translation between Java models in source code and the compiled JS implementation. This change introduces E2eGwtTestCase, which is very similar in syntax and usage to GWTTestCase, by solving problem a and b. Developers do not need to learn JS-based end-to-end testing tools, and can take advantage of IDE support as test code is written in the same language as source code. The ProxyFilter class addresses problem a by proxying requests to user-specified server if it cannot be served by embedded Jetty instance. (The idea came from http://code.google.com/p/google-web-toolkit/issues/detail?id=3131, thank John for pointing it to me). The subclass SyntheticModuleDef is clearer than the current implementation and provides methods specific to synthetic modules that are needed to address problem b.
Future directions: a) support arbitrary host page (add an open() method), or b) test code loads entry point explicitly to gain more flexibility of the execution flow, and c) more features in TestService, such as: wait for synchronous testing, more user-action simulations (type, select, drag&drop). http://gwt-code-reviews.appspot.com/1043801/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
