Testing on the Toilet Aug 7 , 2009 Testing GWT without GwtTest

unalaskaweepingInternet και Εφαρμογές Web

19 Ιουλ 2012 (πριν από 5 χρόνια και 1 μήνα)

290 εμφανίσεις

Testing on the Toilet
Testing on the Toilet
Aug 7
th
, 2009
Testing GWT without GwtTest
Testing GWT without GwtTest
by David Morgan, Christopher Semturs and Nicolas Wettstein based in Zürich, Switzerland
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.
GwtTest is good for testing UI-specific code in JavaScript. If you find yourself using GwtTest 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<Person> 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.

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.
More information, discussion, archives and sourcecode:
http://googletesting.blogspot.com
Copyright © 2009 Google, Inc. Licensed under a Creative Commons
Attribution–ShareAlike 2.5 License (
http://creativecommons.org/licenses/by-sa/2.5/
).