felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Leau <costin.l...@gmail.com>
Subject Re: Library Enabling Test Framework...?
Date Wed, 04 Jun 2008 13:46:40 GMT
Guillaume Nodet wrote:
> Btw, here is an example of such an osgi integration test:
>    http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/jbi/itests/src/test/java/org/apache/servicemix/jbi/IntegrationTest.java

Hi guys,

thanks for pointing out Spring-DM integration testing framework.
There is also a screencast showing its usage on the Spring-DM home page:

Hopefully, you'll find it useful.

If you want to find out more or have any questions, feel free to use teh 
Spring-DM forum (http://forum.springframework.org/forumdisplay.php?f=43).

As for examples, besides Guillaume's code sample and the screencast, one 
can also consider the Spring-DM integration tests (the reason why the 
testing framework was created in the first place).

Costin Leau

> On Wed, Jun 4, 2008 at 3:13 PM, Guillaume Nodet <gnodet@gmail.com> wrote:
>> Once again, I think Spring-DM test support can somewhat fills this gap.
>> From a junit test, it creates an OSGi runtime where you can specify
>> the bundle you want to deploy, then run the junit tests inside the
>> test bundle which is automatically created.
>> I would encourage anyone wanting to do OSGi integration tests to take
>> a look at that first and see if it can fit their use case.
>> On Wed, Jun 4, 2008 at 2:55 PM, Alex Karasulu <akarasulu@apache.org> wrote:
>>> Niclas, Robert,
>>> It sounded to me as if Robert was more interested in a integration testing
>>> framework rather than the build tool used to generate the manifest and build
>>> the bundle.  Please excuse me if I'm wrong here tho.
>>> I just wanted to say that Directory too would like to start using OSGi but
>>> the biggest impediment to date is having a good mini/micro integration
>>> testing framework to test our components in the container right after the
>>> bundle is generated by Maven for that module.  We don't want to have to
>>> create a foo module then a foo-test module just to integration test since
>>> this will lead to a (Maven) module explosion.  It would be nice to have a
>>> JUnit-ish framework for in situ testing OSGi bundles inside target
>>> containers.
>>> Like Robert we want to take bundle foo and make sure if it's a library, the
>>> classes there in function properly by running some tests that access those
>>> classes within the container.  If foo bundle exposes a service we'd like to
>>> get a handle on that service and start running some tests on it etc.
>>> I think such a framework would help increase uptake.
>>> Best Regards,
>>> Alex
>>> On Wed, Jun 4, 2008 at 8:37 AM, Niclas Hedhman <niclas@hedhman.org> wrote:
>>>> On Saturday 31 May 2008 15:02, Robert Burrell Donkin wrote:
>>>>> over in JAMES, we'd like to OSGi enable our upcoming library releases
>>>>> so that they can be used unforked in OSGi environments. the plan is to
>>>>> use the maven plugin but we don't have a lot of OSGi experience. so
>>>>> i'd like to add some integration tests to check that the libraries
>>>>> function ok when used in an OSGi environment. this seems a reasonably
>>>>> general requirement and i was wondering about a general integration
>>>>> testing micro library to test that a library was correctly enabled.
>>>> Robert,
>>>> I think the first necessary step is to incorporate the so called BND tool
>>>> into
>>>> your build. If you are using Maven, then there is a plugin available here
>>>> to
>>>> make it easier.
>>>> BND recursively walks through the classes and figures out what is needed
>>>> and
>>>> compares that against a "recipe" that you specify. The recipe can either
>>>> explicit (in which case every import has to specified or else an error) or
>>>> you use wildcards (less recommended).
>>>> The recipe also contains information about which packages should be
>>>> Exported,
>>>> ignored and kept private.
>>>> With BND it is not too hard to maintain the recipe (typically an external
>>>> file), and will lower the initial need for in-container tests.
>>>> Setting it up is easy, if you know what you are doing, so I suggest that
>>>> someone here volunteers (Stuart???) to help you out.
>>>> Cheers
>>>> --
>>>> Niclas Hedhman, Software Developer
>>>> I  live here; http://tinyurl.com/2qq9er
>>>> I  work here; http://tinyurl.com/2ymelc
>>>> I relax here; http://tinyurl.com/2cgsug
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/

View raw message