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 <[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é (Nanthrax)
BuildProcess/AutoDeploy Project Leader
http://buildprocess.sourceforge.net
[email protected]
PGP : 17D4F086
