4.3.0: Issues with plugin unit testing; oracle plugin integration

Ian Springer ian.springer at redhat.com
Thu Nov 3 20:17:10 UTC 2011


On 11/03/2011 03:02 PM, Elias Ross wrote:
> On Thu, Nov 3, 2011 at 10:56 AM, Ian Springer<ian.springer at redhat.com>  wrote:
>> Hi,
>>
>> Have you looked at some of the other plugins that have integration tests
>> (e.g. the jboss-as plugin)? In those, we do a bunch of filesystem setup
>> for the tests to make sure the plugin container can find the plugin
>> being tested, other dependent plugins, and the platform plugin (which is
>> always required), as well as the SIGAR native libs.
> Now that you mention it, I noticed some stuff going on with copy to
> target/itest, but with the 'snmptrapd' plugin which I worked on (and
> does similar stuff) I don't bother with any copying and tests work
> fine there.
>
> And so...I went and deleted the whole element:
>
>        <profile>
>           <id>integration-tests</id>
>
> and deleted the files under test/itest
>
> and now it works fine! As such, I don't really see it as necessary to
> bother with all the file copying for test purpose. (It does kind of
> raise the question, can't this stuff be put into a parent pom or
> something?)

Interesting, it must be falling back to using the "fake" platform plugin 
then. I think the idea of copying the real platform plugin (as well as 
any plugins the plugin being tested depends on) into a plugins dir to be 
provided to the plugin container was to make the test environment as 
similar as possible to a real environment. And the SIGAR stuff is handy 
to have setup because it allows you to test your server discovery code 
(assuming is uses process scans).

I'm not sure why you were getting classloader issues when you still had 
all the file copying. One idea would be to play with the surefire 
plugin's useSystemClassLoader config prop, which has solved mysterious 
issues for me in the past.

>
> It seems if the plugin doesn't really need to access the platform
> information--many of them do not--then it's basically worthless to
> have this step.
>
> It would be nice if there was a definitive document on unit testing
> your plugin. Anyway, I'm working (or trying to) on a base test class
> for doing testing. 'snmptrapd' has a simple version of what I had in
> mind.

I agree. This is a great idea. If you want to take a stab at a v1 of a 
wiki page, send it to the list so others can review, and then we can get 
it up on the RHQ wiki. I also think it would be very useful if we 
created a base test class and perhaps a new plugin-test-util module to 
contain it - something all plugins could leverage for integration testing.



More information about the rhq-devel mailing list