You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Dave Stanley <ds...@gmail.com> on 2009/10/02 16:20:19 UTC
Re: [DISCUSS] Using SMX4 to test components
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 <cc...@apache.org> 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
>
Re: [DISCUSS] Using SMX4 to test components
Posted by Guillaume Nodet <gn...@gmail.com>.
On Fri, Oct 2, 2009 at 16:20, Dave Stanley <ds...@gmail.com> 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
I've recently added some camel integration tests to do exactly that.
https://svn.apache.org/repos/asf/camel/trunk/tests/camel-itest-karaf/
The tests are disabled for now because there are still a couple of
things to work out, but the basics are here.
> 2) Test the distribution samples using the same approach.
>
> /Dave
>
> On Mon, Sep 28, 2009 at 3:36 PM, Chris Custine <cc...@apache.org> 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
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSS] Using SMX4 to test components
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Charles,
thanks for the update. I saw this code too.
For now, I have upgraded the components-pom to add required dependencies
(pax-exam, etc) and begin to add unit tests in Exec component.
When I will have something clean, I will commit and post a message on
the dev ml. If it's fine for all, I will update the wiki page:
http://servicemix.apache.org/committers-guide.html
with a sub-section in unit test concerning component best practice.
Regards
JB
Charles Moulliard wrote:
> 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 <jb...@nanthrax.net> 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 <ds...@gmail.com>
>>>>> 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 <cc...@apache.org>
>>>>>> 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
>> jbonofre@apache.org
>> jb@nanthrax.net
>> ---------------------------------
>> OpenSource
>> BuildProcess/AutoDeploy
>> http://buildprocess.sourceforge.net
>> Apache ServiceMix
>> http://servicemix.apache.org
>> -----------------------------------
>> PGP : 17D4F086
>>
Re: [DISCUSS] Using SMX4 to test components
Posted by Charles Moulliard <cm...@gmail.com>.
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 <jb...@nanthrax.net> 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 <ds...@gmail.com>
>>>> 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 <cc...@apache.org>
>>>>> 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
> jbonofre@apache.org
> jb@nanthrax.net
> ---------------------------------
> OpenSource
> BuildProcess/AutoDeploy
> http://buildprocess.sourceforge.net
> Apache ServiceMix
> http://servicemix.apache.org
> -----------------------------------
> PGP : 17D4F086
>
Re: [DISCUSS] Using SMX4 to test components
Posted by Jean-Baptiste Onofre <jb...@nanthrax.net>.
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 <ds...@gmail.com>
>>> 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 <cc...@apache.org>
>>>> 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
jbonofre@apache.org
jb@nanthrax.net
---------------------------------
OpenSource
BuildProcess/AutoDeploy
http://buildprocess.sourceforge.net
Apache ServiceMix
http://servicemix.apache.org
-----------------------------------
PGP : 17D4F086
Re: [DISCUSS] Using SMX4 to test components
Posted by Willem Jiang <wi...@gmail.com>.
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 <ds...@gmail.com> 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 <cc...@apache.org>
>>> 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
>>>>
>>
>
Re: [DISCUSS] Using SMX4 to test components
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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.
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 <ds...@gmail.com> 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 <cc...@apache.org>
>> 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é (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
jb@nanthrax.net
PGP : 17D4F086
Re: [DISCUSS] Using SMX4 to test components
Posted by Chris Custine <ch...@gmail.com>.
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 <ds...@gmail.com> 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 <cc...@apache.org>
> 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
> >
>