TotT Testing GWT without GwtTestCase

TotT: Testing GWT without GwtTestCase

Because GWT (Google Web Toolkit) is new and exciting it's easy to forget the lessons on clean GUI code structure that have been accumulated over nearly thirty years.

GwtTestCase is good for testing UI-specific code in JavaScript. If you find yourself using GwtTestCase for testing non-ui client-side logic you may not have a clear View/Presenter separation. Separating the View and the Presenter allows for more modular, more easily tested code with shorter test times. Model View Presenter was introduced in another episode back in February. Here's how to apply it to a GWT app.

Defining terms:

• Server – a completely standard backend with no dependency on GWT.

• Model – the data model. May be shared between the client and server side, or if appropriate you might have a different model for the client side. It has no dependency on GWT.

• View – the display. Classes in the view wrap GWT widgets, hiding them from the rest of your code. They contain no logic, no state, and are easy to mock.

• Presenter – all the client side logic and state; it talks to the server and tells the view what to do. It uses RPC mechanisms from GWT but no widgets.

The Presenter, which contains all the interesting client-side code is fully testable in Java!

public void testRefreshPersonListButtonWasClicked() {
IMocksControl easyMockContext = EasyMock.createControl()
mockServer = easyMockContext.createMock(Server.class);
mockView = easyMockContext.createMock(View.class);
List franz = Lists.newArrayList(new Person("Franz", "Mayer"));
mockServer.getPersonList(AsyncCallbackSuccessMatcher<list<person>>reportSuccess(franz)));
mockView.clearPersonList());
mockView.addPerson(“Franz”, “Mayer”);
easyMockContext.replay();
presenter.refreshPersonListButtonClicked();
easyMockContext.verify();
}

Testing failure cases is now as easy as changing expectations. By swapping in the following expectations, the above test goes from testing success to testing that after two server failures, we show an error message.

mockServer.getPersonList(AsyncCallbackFailureMatcher<list<person>>reportFailure(failedExpn))
expectLastCall().times(2); // Ensure the presenter tries twice
mockView.showErrorMessage(“Sorry, please try again later”));

You'll still need an end-to-end test. But all your logic can be tested in small and fast tests.

The Source Code for the Matchers is open-sourced and can be downloaded here: AsyncCallbackSuccessMatcher.java - AsyncCallbackFailureMatcher.java.

Consider using Test Driven Development (TDD) to develop the presenter. It tends to result in higher test coverage, faster and more relevant tests, as well as a better code structure.

This week's episode by David Morgan, Christopher Semturs and Nicolas Wettstein based in Zürich, Switzerland – having a real Mountain View

Toilet-friendly version

AsyncCallbackSuccessMatcher.java

AsyncCallbackFailureMatcher.java.