4.3.0: Issues with plugin unit testing; oracle plugin integration

Elias Ross genman at noderunner.net
Fri Nov 4 17:39:10 UTC 2011


On Thu, Nov 3, 2011 at 1:23 PM, Heiko W.Rupp <hrupp at redhat.com> wrote:

> Did you have a look at Arquillian for this purpose? We probably would
> need to write a rhq-plugin-container adapter, but then Arquilian could
> take care of starting the container, deploying what is needed and so on.

Arquillian would be ideal to run your plugin in an actual plugin
environment, but there's a lot of infrastructure required for setting
up configuration and obtaining references to ResourceComponents and
the like. I wouldn't know where to begin with initializing and
communicating with the plugin container remotely, but I suppose
Arquillian could bootstrap it locally.

As for referring to resources, it would be best to have some sort of
'CDI'-like annotations injection mechanism. In fact, it would be nice
to have annotations-based plugin definitions rather than having to
write XML.

Again, as you would have to bootstrap the plugin container each run,
it might be a bit frustratingly slow to test. (This could be
optimized, I suppose, to start dependencies on demand. See 'CDI'
above.) I kind of like that my tests run in a matter of seconds,
rather than tens of seconds.

For the curious, here's a little 'code preview' of what I'm doing.
ComponentTest is a base test for testing plugin components. (For now
it resides with the Oracle plugin itself.) It basically does the job
of setting up the plugin container and creating all the resources in
rhq-plugin.xml .

public class OracleServerComponentTest extends ComponentTest {

    private static final String ORACLE_SERVER = "Oracle Server";
    private ResourceComponent<?> server;

    @BeforeTest
    @Override
    protected void before() throws Exception {
        super.before();
        server = byName(ORACLE_SERVER); // obtains reference to
component by name
        details = byName("Oracle Advanced Statistics");
    }

    @Override
    protected void setConfiguration(Configuration configuration,
ResourceType resourceType) {
        if (resourceType.getName().equals(ORACLE_SERVER)) {
            String url = System.getProperty("oracle.url");
            configuration.getSimple("host").setStringValue( ... );
...

    @Test
    public void up() throws Exception {
        assertUp(server);
        MeasurementReport report = getMeasurementReport(server);
        Double rt = getValue(report, "totalSize");
        assertTrue(rt > 100);

For most plugin development, this is what you spend your time doing:
1. Ensure the XML descriptor parses fine. This is easy to spend hours
on, especially if you are a N00b like me.
2. Ensure your code starts fine and discovery works as you expect.
3. Ensure availability states such as 'up' and 'down' are what you expect.
4. Ensure the measurement information is what you expect.
5. Ensure event data is coming back.

I haven't gotten into other use cases, like operations and whatnot,
but just having a way to do 1-5 is big and is almost entirely what I
need for my use.

A CDI/Arquillian type approach would probably have tests that look like this:

public class OracleServerComponentTest extends Arquillian {

    @Inject
    private OracleServerComponent server;

    @SomeAnnotation(name="Oracle Advanced Statistics")
    private ResourceComponent details;

    @Deployment
    protected void init() throws Exception {
/* not entirely sure how you could configure components? */
}


More information about the rhq-devel mailing list