This post is about how to get common bindings for Jukito tests without having to write too much boilerplate. (Obviously not a general interest post!)
A recent conversation on the Jukito newsgroup discusses various proposals for reducing the amount of boilerplate involved in setting up common bindings for tests that have a common superclass. I've noticed that the underlying assumption to these proposals is that bindings in modules are inheritable in the same way that methods are, but that's not generally the case. You can override methods by defining a new version in a subclass, but to override the bindings in a module, you need to use Modules.override, which doesn't work via inheritance.
I've written a template to illustrate how to override with test bindings; it uses Jukito 1.1 as is:
http://pastebin.com/BLQnMEqx
The key is to declare a static method in a common test superclass that returns a single module, which is easy to do with Modules.combine. Then in the concrete test class, use
Modules.override(commonBindings).with(testBindings)
This strikes what I think is the right balance between compactness and clarity: You have one place in the concrete test class that says what the basic bindings are (commonBindings) and what test bindings are being used to override for the purposes of this test (testBindings). There's no hunting around through the inheritance hierarchy for modules with the right characteristics.
Because the Modules.combine/override approach is so simple, the case for adding special Jukito support (based on inheritance alone, annotations alone, or on a combination of inheritance and annotations) for auto-installing commonly-used modules becomes much weaker. Jukito is already pretty magical; it doesn't need to add mystery to its magic.
