Arquillian integration

Lukas Krejci lkrejci at redhat.com
Wed Feb 29 15:08:29 UTC 2012


I think most if not all of the requirements you listed below are a matter of providing utility methods and/or annotations so that the test doesn't have to get that information "manually" from the PluginContainer.

My work on the arquillian integration was just a start - I spent only like 2 days familiarizing myself with Arquillian/Shrinkwrap and producing a first cut implementation. I am quite happy with where I got in such little time. Standing up a plugin container with your plugin (including all the dependent plugins) is now much easier, imho, and it doesn't require any magic ant scripts in your POM. I think that is a major win by itself. 

Apart from enriching the API provided by this integration, I think for the plugin testing we need to focus on some ways of helping the tests mock the managed resources the plugins talk to. But since our plugins use such a wide variety of approaches to talk to the managed resources, I don't think we can do much there.

For testing of plugin container itself, we need a way of configuring the server services - i.e. the "communication providers" that the plugin container uses to exchange information with the RHQ server. This is something that has not been yet incorporated into the RHQ's arquillian API.

But anyway, your response is exactly what I was hoping for, very much appreciated. Now we can work on adding more utilities to the infrastructure.

Please see my replies below.

----- Original Message -----
> From: "Elias Ross" <genman at noderunner.net>
> To: rhq-devel at lists.fedorahosted.org
> Sent: Tuesday, February 28, 2012 9:21:01 PM
> Subject: Re: Arquillian integration
> 
> I welcome better testing for plugins, but I don't necessarily see the
> Arquillian solution as easy (currently) as my ComponentTest code.
> 
> Some of this could be solved in conjunction with more injection
> support and utility classes.
> 
> Use cases to fullfill:
> 1) Need to test the existing plugin XML plugin as-is, including
> dependent resources

I think I don't understand exactly what you are after here. But if I understand it correctly you want to be able deploy multiple plugins into a plugin container and discover the whole resource hierarchy? If that is what you meant, then I think it's exactly what my approach enables. Because it is running the full plugin container behind the scenes and is able to easily deploy plugins (along with dependencies) to it, you basically have the whole fully functioning (embedded) agent at your disposal.

> 2) Need a way to configure plugins prior to discovery programmatically

If a discovery component implements ManualAddFacet, it can be passed a plugin configuration for the manual discovery. The autodiscovery is autonomous and shouldn't require any configuration (apart maybe from configuration of parent components). Again because we're running a full PluginContainer, this is of course possible - maybe the API isn't that nice from testing perspective (the API is tuned for server-agent communication) but it is certainly possible.

> 3) Retrieve a discovered resource by name and/or by class type

This is a clear candidate for a utility method.

> 4) Retrieve the plugin descriptor by resource type

I don't think this makes sense, because resource types are *created* from their descriptors. I.e. the resource type contains all the data you specified in the descriptor.

> 5) Obtain metrics, compare the list of metrics obtained from a
> resource with the resource descriptor

You mean to test if the results of getValues() corresponds to the format defined in descriptor? That's a nice candidate for a utility method, too.

> 6) Test if resources are available

I think, the framework goes quite a long way here and I'm not sure if it should go further. Because you can get the resource components using the @ResourceComponentInstances annotation, you can call their methods directly. So this actually is already as easy as asserting the result of your resource component's getAvailability() call. Or did I misunderstand your point?

> 7) Obtain events

Again, the API may not be super intuitive, but you have at your disposal a full running PluginContainer. Obtaining events is therefore possible.

> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
> 


More information about the rhq-devel mailing list