If you’re writing a GWT application you are most likely following the MVP pattern. With GWT 2.1 the Activities and Places API was introduced and while it’s not strictly an MVP framework, it’s a good base for the architecture of your application.

A core component of Activities and Places is the ActivityMapper interface. Its role is simple - you get a Place and based on it an appropriate Activity should be returned. There’s one problem - you most likely will want to choose the Activity based on the type of the provided Place. The usual approach (mentioned even in the official documentation) is a long chain of if (place instanceof CustomPlace) else if (place instanceof CustomPlace2)… etc. You might have a similar if/else chain somewhere else in your application where you want to react to a PlaceChangedEvent. If you add a new Place, you have to remember to add (another…) if else in all those places.

Continuing the theme of testing with gwtmockito, I’d like to show you a neat class that’s bundled with gwtmockito that allows for easy mocking of GWT-RPC asynchronous services.

The class I’m talking about is AsyncAnswers. It’s meant to be used with the doAnswer stubber.

Supposing we have a LoginServiceAsync class:

public interface LoginServiceAsync {
    void login(String login, String password, AsyncCallback<SomePojo> callback);
}

Assuming service is a mock for LoginServiceAsync, we could simulate a successful trip to the server with:

gwteventbinder and gwtmockito are great projects that are esential if you’re writing applications in Google Web Toolkit/GWT. So it was a surprise to me that they don’t play together well “out of the box”.

See, the problem is that gwtmockito injects it’s own (safe, not using any code that requires running a browser) mocks when it encounters GWT.create in your code. That’s very cool, but when using gwteventbinder, you need to call the bindEventHandlers method to, well, bind the event handler. And the mock, obviously, doesn’t do that.