Testing GWT Events

I’m working on my first GWT application.  In the process of trying to test some event-driven code, I was seeing that my events were being picked up by objects registered from previous tests.

This was due to the way I was instantiating my EventBus instance:

public static final EventBus eventBus = new SimpleEventBus();

This meant that, between tests, instances of previous texts fixtures were still being held by the eventBus.

I shouldn’t have been surprised.  I try to avoid statics for the most part.  They tend to get me into trouble.  If it’s a primitive value, that’s one thing.  But a core item like the event bus?  I should have known it was a bad idea.

I’m using Google Gin in GWT and Google Guice in the server-side code.  So I looked for a way to inject the code.  My problem was with more static code.  I followed the idiom I had seen, I think, in a Google presentation.  The code looked something like this:

MyEvent.register(new MyHandler() { ... });
...
MyEvent.fire(new MyEvent(...));

That code is quite convenient to use.  Statics are convenient in a lot of cases. But the problem comes in when you want anything to vary. Want polymorphism? No chance. Want to swap instances? Not going to happen.  Statics are convenient, but that convenience comes at a price, and I tend to be cheap.

My first thought was to create instances of my event classes and inject them in where I needed them. The obvious problem with that is that some classes register for several events. Injecting in all of those events starts to smell. Further, what would I inject? Instances of the events themselves? That is also odorous. In the code with the statics, the classes is playing two roles: managing the events and then being the event itself. So I could create a sort of “event manager” for each of my events, but I’m still left with a lot of things to inject.

Instead, I came up with a compromise. I created a class for registering and firing events that held my EventBus instance, but kept the events separate. I called this the EventBroker and it looks like this:

class EventBroker {
  private EventBus eventBus;
  @Inject
  public EventBroker(EventBus eventBus) {
    this.eventBus = eventBus;
  }
  public HandlerRegistration registerMyHandler(MyHandler handler) {
    return eventBus.addHandler(MyEvent.TYPE, handler);
  }
  public void fireMyEvent(MyEvent event) {
    eventBus.fireEvent(event);
  }
  // more register and fire methods ...
}

This allows me to register a single instance of my EventBus in Gin or Guice (Guice for unit tests). I may either register a single instance of EventBroker or let Gin create one each time I ask: it doesn’t matter because I always have one EventBus instance.

As you might imagine, the interface to EventBroker may become quite large. However, I can create an EventBroker for any subset of events I choose, and so have some reasonable number of EventBroker classes, all using the same EventBus instance. This seems not much worse than the static code idiom in terms of convenience, but much more powerful for unit testing.

One additional note: these methods seem to cry for the use of generics.  But I can’t seem to make it work.  If you have any ideas, I would appreciate it!