When it comes to testing the code of a GWT-based application there's many things to consider. One thing that's for sure: its a good approach to use MVC/MVP to minimize the code that is actually dependent on GWT - all other code can then be tested with pure JUnit.
Talking about the GWT-dependent code there's different approaches that all have their strengths and weaknesses. The fact we want to use GXT adds additional complexity.
GWT provides an integration with Junit. By extending the provided GWTTestCase one can write unit-tests that will start an gwt-environment behind the scenes in order.
- available out-of-the-box
- tied to JUnit3-style of writing tests (no annotations)
- run orders of magnitudes slower than ordinary JUnit-tests
- only restricted usage of Java-classes (e.g. no Reflection and hence no usage of mocking-frameworks)
Run into Classpath problem due to the fact that gwt-dev includes a version of nekohtml. When we want to write such tests, we have to resolve this.
In Eclipse, the containing project must have GWT-enabled in order to have the Run GWT JUnit Test to show up
GWT contains a class GWTMockUtilities intended for mocking GWT tests. As that implementation always returns null when calling GWT.create() you'll very likely run into NullpointerExceptions. That's why it's better to use an implementation that actually creates mock objects.
- fast - no GWT-environment is started behind the scene
- Junit4-style can be used (in contrast to GWTTestCase)
- not easily appliable to GXT2.x due to some implementation details
- some of this issues can be worked around e.g. by not directly using the GXT-types but adapters
- GXT3 will contain the required changes.
- seams to be very powerful (even events can be tested)
- looks like it's not very wide spread (although activity seams to be high)
- quite complex to set up (uses bytecode enhancement - a java-agent has to be added when launching the JVM)