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.
However, there’s a solution -
FakeProviders. By registering one for the
EventBinder interface, it will be used for providing instances of
EventBinder and its subclasses. Unfortunately,
EventBinder uses a GWT Generator for it’s implementation, and to “emulate” that during our tests, we have to resort to Java Reflection.
The following implementation is inspired by comments and suggestions from an issue raised on gwteventbinder’s tracker. You can find alternative solutions there, too.
It’s not as bad as it seems. When you get rid of the Java Reflection cruft, it boils down to:
- Find all the methods on the presenter that are annotated with
- Register a new handler that invokes the callback method for the event specified as it’s first argument.
- Return a
HandlerRegistrationinstance that on call to
removeHandlerremoves all the handlers added in the previous point (this behavior is copied from the actual implementation of gwteventbinder).
You might note that I don’t do any safe-checks… Well, assuming that you’ve run your code before, using (Super)DevMode, the EventBinder’s generator already checked that your code is sane and within the requirements of gwteventbinder.
Now, all that’s left is to register this provider, for example in your
Like I’ve already mentioned, you only need to do this for the base interface,
EventBinder, since as the documentation for
(..) the given provider should be used to GWT.create instances of the given type and its subclasses.