In addition to occasional development work on the Openfire core, I have also been busy building various custom extensions (plugins and components) for Openfire. Part of this work has been to build some limited support for proxying certain parts of the Openfire API so that we can build mock implementations and perform proper unit testing of our custom classes. For example, using JiveGlobals to fetch configuration properties works fine in a real Openfire container, but is problematic if you are trying to isolate a plugin for unit testing. Same goes with User/UserManager, PluginManager, and other common API classes that were not designed with mocking in mind.
Ideally what we would like is a relatively easy way to selectively hide the Openfire implementation behind an interface (if one does not exist already) with a default implementation that can easily swapped (via JMock) or extended via inheritance to override default container-dependent behavior.
Note that (locally) I have also extended the base Openfire build.xml and build-time dependencies to add Emma capabilities (code coverage) when running our unit tests. You might know that JMock is already included with the Openfire distribution, so in effect we are rounding out support for continuous integration when extending Openfire with our own custom/third-party plugins.
My question is, would you like to see these proxy/mock classes and supporting utilities added to the core Openfire project? I could provide some usage documentation and examples of how we use this approach to test our code (up to 100% coverage on functional classes). I would propose adding a couple of new packages, as follows:
org.jivesoftware.openfire.proxy - Proxy interfaces with default implementations for certain parts of the Openfire API
org.jivesoftware.openfire.mock - Mocked core classes, such as MockPluginManager, plus mocked proxy implementations
Do you think these kinds of interfaces and classes belong in the Openfire core? Should they be instead separated out as a plugin SDK or similar separate project? Do you really even care that much about unit testing, code coverage, and continuous integration for Openfire plugins?
I'd be interested in your feedback on this topic. Feel free to reply in the comments below.