Hi David,

the idea behind exam (same in drone) is to spawn a new osgi framework
instance, make a bundle out of the testcase on the fly (that was called
"drone", which was the reason for pax drone's name), installed in the osgi
instance. The "Bundle on the fly" also registers a service which delegates
to our test methods. Then you can easily execute the service with standard
osgi means.

So, your test is not a fake of a bundle, or a so called bundle, it IS a
bundle.

Since our only (and default) a pax runner (the mother of all osgi
frameworks) the osgi framework is started as a separate java vm process. To
let the runner trigger the test service execution, we expose a minimal
control service via RMI. Still, the testcase is part of the osgi eco system.

Now, some may not want to have the test to be part of the osgi system so we
are planning to have a config option to let the test run in your (IDE) jvm.
Then your osgi app should have some things installed that are remotly
observable (thus subject of test).
Then you are completely on your own and don't have access to the osgi
contexts/services by default.

HTH

cheers,
Toni

On Mon, Jan 12, 2009 at 2:44 AM, David Leangen <[email protected]> wrote:

>
> Hey, Toni,
>
> Great work!
>
> I've not yet used Pax Drone, so I'm not entirely sure how this works,
> but...
>
> What interests me is how you obtain services from other bundles in the test
> context, and how you would set up which bundles are available in the test
> context as well. Can you please explain that a little?
>
>
> Thanks!
> =dml
>
>
>
>
> -----Original Message-----
> *From:* [email protected] [mailto:
> [email protected]]*on Behalf Of *Toni Menzel
> *Sent:* 12 January 2009 00:18
> *To:* General OPS4J
> *Subject:* Ask ops4j: Get in touch with pax exam, need your help
>
> Gang,
> First of all, Happy New Year to all @ops4j!
> The new Pax Exam (former pax drone) is going more and more concrete.
> Now, we would like to get your opinion in some of the designs.
>
> Imagine a test like you know (using Junit4):
>
> @RunWith( JUnit4TestRunner.class )
> public class SimpleTest
> {
>     @Test
>     public void defaultBundles( final BundleContext bundleContext )
>     {
>         assertEquals( 9, bundleContext.getBundles().length );
>     }
> }
>
> Note, the initial RunWith tells the runner to use Pax Exam instead of the
> standard junit4 runner.
> Basically you are done now. Now begin writing tests with standard Junit4
> @Test annotation.
>
> Now, you want to configure you osgi testcontainer in a certain way (select
> framework, add bundles and 100 things more)
> You can do that by adding a method to you class that has the @Configuration
> annotation:
>
> @RunWith( JUnit4TestRunner.class )
> public class SimpleTest
> {
>
>     @Configuration
>     public static Option[] configureToUse()
>     {
>         return options(
>           logProfile(),
>           equinox()
>         );
>     }
>
>     @Test
>     public void defaultBundles( final BundleContext bundleContext )
>     {
>         assertEquals( 9, bundleContext.getBundles().length );
>     }
> }
>
> Now, you have equinox and the log profile (from paxrunner) enabled.
>
> New in Pax Exam is the ability to have multiple configurations.
> So you can run for example the same test with two different framework
> versions.
> Now, you have to wire configurations to testcases.
> We currently have two approaches to that:
> @RunWith( JUnit4TestRunner.class )
> public class SimpleTest
> {
>
>      @Configuration
>     public static Option[] configure()
>     {
>         return options(
>             logProfile()
>         );
>     }
>
>     @Configuration
>     @AppliesTo( "junitBundlesSpecified.*" )
>     public static Option[] configureAnotherVersionOfJUnit()
>     {
>         return options(
>             junitBundles().version( "4.5.0" )
>         );
>     }
>
>     /**
>      * Tests that the provisioned JUnit bundles are the default ones
> (4.4.0).
>      */
>     @Test
>     public void junitBundlesNotSpecified()
>     {
>
>     }
>
>     /**
>      * Tests that the provisioned JUnit bundles are the specified ones
> (4.5.0).
>      */
>     @Test
>     public void junitBundlesSpecified()
>     {
>
>     }
> }
>
> See that there is the @AppliesTo annotation involved. This is a regular
> expression for test method names.
> So we assign one configuration just to test methods starting with
> junitBundlesSpecified.
> The other configuration is added to all tests (default value of appliesTo
> is ".*")
>
> We think of another approach to assign them, without relying to method
> names:
> @RunWith( JUnit4TestRunner.class )
> public class SimpleTest
> {
>
>      @Configuration
>      @Context( "standard" )
>     public static Option[] configure()
>     {
>         return options(
>             logProfile()
>         );
>     }
>
>     @Configuration
>     @Context( "junitBundlesSpecified" )
>     public static Option[] configureAnotherVersionOfJUnit()
>     {
>         return options(
>             junitBundles().version( "4.5.0" )
>         );
>     }
>
>     /**
>      * Tests that the provisioned JUnit bundles are the default ones
> (4.4.0).
>      */
>     @Test
>     @Context( "standard" )
>     public void junitBundlesNotSpecified()
>     {
>
>     }
>
>     /**
>      * Tests that the provisioned JUnit bundles are the specified ones
> (4.5.0).
>      */
>     @Test
>     @Context( "standard","junitBundlesSpecified" )
>     public void junitBundlesSpecified()
>     {
>
>     }
> }
>
> Here we use context annotation to wire them. Default context is "" so you
> still can go completely without context.
> This is much more typing, but does not glue together method names and
> annotation values but completely relies on annotation data.
>
> What do you think ?
> You can find all this here
> https://scm.ops4j.org/repos/ops4j/projects/pax/exam
> And see some examples here:
> https://scm.ops4j.org/repos/ops4j/projects/pax/exam/pax-exam-it-01
>
> Feel free to ask try it out and discuss.
> Any comments+contributions are welcome!
> cheers,
> Toni
>
> --
> Toni Menzel
> Software Developer
> [email protected]
> http://www.ops4j.org     - New Energy for OSS Communities - Open
> Participation Software.
>
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
>


-- 
Toni Menzel
Software Developer
[email protected]
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general

Reply via email to