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.
Approaches
GWTTestCases
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-Mock-Tests
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.
GWT-test-utils
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)