Hi,
Another interesting implementation of PAX-exam for Apache Felix Karaf
has been made here :
D:\Dvlpt\Java\workspace-ganymede\apache-felix\karaf\itests\src\test\java\org\apache\felix\karaf\shell\itests
Remark :
I propose to use scanFeatures in the option configuration of the class
defining the configuration of the felix/equinox server
@Configuration
public static Option[] configuration() {
Option[] options = options(
This will help us to run the test according to different
versions/packages of Apache Felix Karaf or ServiceMix 4.
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
On Sat, Oct 3, 2009 at 10:17 AM, Jean-Baptiste Onofre <[email protected]> wrote:
> Thanks Willem for your comment. Guillaume has spotted this source code too.
>
> I will begin to implement this in some components (RMI, Exec, SMPP, ...) to
> see how it works.
>
> Regards
> JB
>
> Willem Jiang wrote:
>>
>> Hi,
>>
>> My comments are inline.
>> Jean-Baptiste Onofré wrote:
>>>
>>> Hi all,
>>>
>>> I think that we need to see the unit tests in two sections:
>>>
>>> 1/ JBI oriented tests
>>> Currently, most of the component unit tests usage the embedded SMX3 form.
>>> For example, we use:
>>>
>>> JBIContainer container = new JBIContainer();
>>> container.setUseMBeanServer(false);
>>> container.setCreateMBeanServer(false);
>>> container.setEmbedded(true);
>>>
>>> and after we deploy the component:
>>> Component component = new Component();
>>> container.activateComponent(component, "MyComponent");
>>> container.start();
>>>
>>> and finally, we deploy the SU using a xbean file for example:
>>> component.getServiceUnitManager().deploy("test",
>>> xbeanPath.getAbsolutePath());
>>> component.getServiceUnitManager().init("test",
>>> xbeanPath.getAbsolutePath());
>>> component.getServiceUnitManager().start("test");
>>>
>>> The JBIContainer comes from SMX3. For this part, to guarantee that the
>>> component is fully JBI compliant, in the unit test, we can:
>>> 1/ start a karaf instance
>>> 2/ deploy NMR feature into karaf
>>> 3/ use a kind of testing API to manage the component deployment and SU
>>> testing
>>> I'm quite sure that all these steps can be achieve but I propose to
>>> provide an embedded testing distro.
>>>
>>> 2/ OSGi tests
>>> A component is a bundle too. The unit tests have to test that this bundle
>>> deploy correct into a karaf instance.
>>> Maybe for this part, we can use PAX-Exam.
>>
>> Here are some camel examples which use karaf features to install the
>> bundles and run the unit test with PAX-Exam.
>> Since some tests will make the CI hang for a while , we disable the test
>> running from mvn.
>>
>> [1] https://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-osgi
>>
>>
>> Willem
>>>
>>> Thoughts ?
>>>
>>> Regards
>>> JB
>>>
>>> Chris Custine wrote:
>>>>
>>>> Hi Dave,
>>>> Yes, that is exactly what I was thinking. Although for features
>>>> installs, I
>>>> am actually working on a larger package acceptance test within the
>>>> actual
>>>> assembly module. I like your suggestion about the sample and the
>>>> assembly
>>>> itests would be a good place for those as well.
>>>>
>>>> So for the ocmponents, not only will we be testing the functionality,
>>>> but we
>>>> can also verify proper deployment and installation lifecycle. I had
>>>> started
>>>> some tests already, so I am going to look over Guillaume's tests and
>>>> compare.
>>>>
>>>> Any other suggestions are welcomed!
>>>>
>>>> Chris
>>>> --
>>>> Chris Custine
>>>> FUSESource :: http://fusesource.com
>>>> My Blog :: http://blog.organicelement.com
>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>> Apache Directory Server :: http://directory.apache.org
>>>>
>>>>
>>>> On Fri, Oct 2, 2009 at 8:20 AM, Dave Stanley <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Chris,
>>>>> I think it makes a lot of sense. I would also be interested to see if
>>>>> we
>>>>> could also
>>>>>
>>>>> 1) Test features install cleanly
>>>>> 2) Test the distribution samples using the same approach.
>>>>>
>>>>> /Dave
>>>>>
>>>>> On Mon, Sep 28, 2009 at 3:36 PM, Chris Custine <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Jean-Baptiste suggested in another thread that we consider moving to
>>>>>> SMX4
>>>>>> for component testing, and this has also crossed my mind recently so
>>>>>> we
>>>>>> thought it bet to start a specific thread to discuss this.
>>>>>>
>>>>>> I think it will certainly be a requirement to automate testing of
>>>>>> components
>>>>>> inside SMX4, but there are also some more immediate motivations for
>>>>>> doing
>>>>>> this in order to test components with updated dependencies used in
>>>>>> SMX4.
>>>>>> After using Pax Exam a bit lately with the SMX4 itests, I am wondering
>>>>>> if
>>>>>> that would be a suitable mechanism to test components with SMX4? I
>>>>>> think
>>>>>> this would certainly be a more accurate test of integration with the
>>>>>> runtime
>>>>>> than the current tests, although there will possibly be a performance
>>>>>> penalty when running tests due to the more heavyweight nature.
>>>>>> Alternatively, we could bootstrap some smaller chunk of SMX4 in order
>>>>>> to
>>>>>> perform more isolated tests without starting a full container.
>>>>>>
>>>>>> I am currently leaning towards using Pax Exam because it would provide
>>>>>> a
>>>>>> very accurate representation of the component running inside the
>>>>>
>>>>> container.
>>>>>>
>>>>>> This would include deployment and startup lifecycle, interaction with
>>>>>> runtime dependencies, etc. which is slightly more accurate than the
>>>>>
>>>>> current
>>>>>>
>>>>>> tests.
>>>>>>
>>>>>> One final question is whether SMX4 provides an adequate test
>>>>>> environment
>>>>>> that is reciprocal with SMX3. We have been relying on SMX3 for
>>>>>> testing
>>>>>> components that are also deployed in SMX4, so is this also good enough
>>>>>
>>>>> the
>>>>>>
>>>>>> other way around or do we need to keep both? One of the downsides of
>>>>>> the
>>>>>> current tests is that many of the components have their own base tests
>>>>>
>>>>> that
>>>>>>
>>>>>> create the appropriate environment in which to test, and I think this
>>>>>> has
>>>>>> made the tests harder to maintain. I think one of the goals for this
>>>>>
>>>>> would
>>>>>>
>>>>>> be to make test authoring much easier.
>>>>>>
>>>>>> So what are everyone's thoughts on this?
>>>>>>
>>>>>> Thanks,
>>>>>> Chris
>>>>>> --
>>>>>> Chris Custine
>>>>>> FUSESource :: http://fusesource.com
>>>>>> My Blog :: http://blog.organicelement.com
>>>>>> Apache ServiceMix :: http://servicemix.apache.org
>>>>>> Apache Directory Server :: http://directory.apache.org
>>>>>>
>>>>
>>>
>>
>
> --
> Jean-Baptiste Onofré
> ---------------------------------
> HomePage
> http://www.nanthrax.net
> ---------------------------------
> Contacts
> [email protected]
> [email protected]
> ---------------------------------
> OpenSource
> BuildProcess/AutoDeploy
> http://buildprocess.sourceforge.net
> Apache ServiceMix
> http://servicemix.apache.org
> -----------------------------------
> PGP : 17D4F086
>
