Any interest in mocking for Openfire plugins, components?

Openfire Openfire Dev
1

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.

2

Tom,

You’ve always done a great job standing behind the code you kindly sent us. As long as you continue with that for what you are intending to send now, I see no reason to object Unfortunately, I can’t offer code opinions and Guus is very busy these days. Maybe csh or flow have thoughts.

daryl

3

In my opinion such mock-/helper-/util-classes which are exclusively required for testing should belong in a separate “test-jar” and should not be distributed with the normal Openfire installation.

Speaking for Maven you would generally create a separate “test-module”, which contain these classes. This project would be built separately as “test-jar” and would be referenced by the plugins which need it.

See also here: testing - Sharing Test code in Maven - Stack Overflow

So, my vote goes for “plugin SDK or similar separate project”. Please not in the “main” src folder. Maybe a 3rd project which contains interfaces, which are shared between the core and the test project is needed too.

Do you really even care that much about unit testing, code coverage, and continuous integration for Openfire plugins?

It’s certainly a good idea. As for now, you have to code “in the dark”, build plugin jar, copy the jar to the Openfire installation and test it in the running system. Then repeat for every error you find.

Guus is very busy these days

Hm, there are many open issues, which require or ask for Guus’ opinion/decision. Hopefully he’ll find some time.

4

What CSH said. Test code does not belong into the core IMHO. I tend to place mocked classes in the same package as the original ones, just in a different (test) project, instead of creating a extra package for them.

But since I’m not really that much involved in openfire development I don’t care that much.