dependency problem with drift tests
John Sanda
jsanda at redhat.com
Fri Oct 28 14:35:59 UTC 2011
We hit a problem last night with drift tests in the server/jar module
that needs to be addressed after the 4.2 release. I will describe the
problem followed by my proposed solution.
problem:
DriftManagerBean delegates to a server plugin to handle persistence of a
lot of the drift-related entities. Recently I started adding more tests
to exercise functionality in DriftManagerBean. Tests now call through to
the server plugin. Here is the issue. The server/jar module is built
before the server plugins; so, when the drift tests are run (from a
clean work space) they will fail because the server plugin container
won't have a plugin jar file to load since it has not been built yet.
solution:
One possible solution would be to move the tests to the drift-rhq server
plugin module so that they run after both server/jar and the plugin are
built. I think that there is a better solution though. We move the
tests, along with some others, to a separate integration test suite
module. We set up a new jenkins job to run those integration tests after
each run of the master job.
There are two benefits to this approach. First, these tests can be used
with other drift server plugin implementations. This could provide a
really nice test harness for the plugins.
Secondly and more importantly, we are headed down an unsustainable path
with respect to build execution time for server/jar. A couple weeks ago
I had to run all of the server/jar tests in order to reproduce some
failures that were happening on jenkins. On my quad core box with 16 GB
of ram, it took over 17 minutes to run the tests. I want to move some of
these tests over to the integration test suite module. This will help
reduce overall build times for the master job on jenkins, and will also
make it a little more palatable for people to run all of the server/jar
tests before a commit and/or push.
- John
More information about the rhq-devel
mailing list