tags:

views:

3468

answers:

3

What is the best way to test GWT code?

GWTTestCase in hosted mode is too slow and none of the mocking frameworks work.

Currently we are following MVC as suggested in http://robvanmaris.jteam.nl/2008/03/09/test-driven-development-for-gwt-ui-code/ and using GWTMockUtilities disarm() and restore() to mock widgets. And we havent figured out a way to test View in GWT MVC. Is there a better way to test GWT code?

+5  A: 

If you're looking to test GWT widgets in isolation, there aren't many options. You can use a GWTTestCase to instantiate your widgets and test it through its API, which is what Google does for the GWT widgets themselves: http://google-web-toolkit\.googlecode\.com" title="Source for RadioButtonTest">Source for RadioButtonTest

However, the event-firing mechanism doesn't work in GWTTestCases, which means you can't do things like programmatically click a button and expect some onClick() callback method to be invoked on a listener. It also is hard if not impossible to get at the underlying DOM, so it may not be the best tool for testing low-level HTML-emitting code.

It sounds like you are following all the right steps; Rob's article provides an excellent description of how to write testable code using the Model-View-Presenter (MVP) design pattern. The more logic you keep out of the view layer, the better. When that's not possible, use a tool like Selenium to create focused tests of dynamic UI behavior.

I followed a similar strategy - MVP with minimal code in the widgets. In a few cases I did write some code which would wrap the Grid class, so I was able to instantiate my component in a GWTTestCase, pass it a Grid, invoke some methods on my component, and check the state of the Grid. I wrote an article for Better Software about Test-First GWT, which you can read on my blog.

If you're looking to test code that uses non-UI GWT classes (such as URL encoding or Dictionaries), you'll need to use GWTTestCase, or else follow similar wrapping strategies until the code is too simple to break. Then use an integration test with a tool like Selenium, or a few targeted GWTTestCases which only test that you're using the library correctly -- as J.B. Rainsberger says, "Don't test the framework!"

+3  A: 

What worked for me:

Use classical model/view/controller (e.g. no business logic in the view or controller; controllers only translate view events into method calls on the model).

Decouple the model and controller code from the GWT view widgets and any other classes that rely on GWT and can't be instantiated in a plain old JVM. You can then test them with good old JUnit.

Write end-to-end tests to test the system through the GUI to ensure that the models and controllers are hooked up to the views correctly. We found it faster to deploy and start up the app and then interact with it through a browser controlled from JUnit with WebDriver than to use GWTTestCase!

Use JMock to test asynchronous calls like this: http://www.jmock.org/gwt.html.

Nat
+1  A: 

Also have a read at Testing Methodologies Using Google Web Toolkit

Iker Jimenez