You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Ian Boston <ie...@tfd.co.uk> on 2013/04/12 01:40:43 UTC
Generalising Pax Exams
Hi,
I seem to do a lot of mocking, which although relatively painless and
reliable, doesn't test the finer points of spinning up a service in OSGi.
Last year I wrote [1] to make it simple to do Pax Exams, used by [2].
Could/should this be made more generally available ? It fits mid way
between a mocked test and a full blown IT.
Ian
1
http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/cache/container-test/
http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/cache/container-test/src/main/java/org/apache/sling/test/AbstractOSGiRunner.java
2
http://svn.apache.org/repos/asf/sling/trunk/contrib/extensions/cache/ehcache/src/test/java/org/apache/sling/commons/cache/ehcache/CacheIT.java
Re: Generalising Pax Exams
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Apr 12, 2013 at 10:50 AM, Carsten Ziegeler <cz...@apache.org> wrote:
> I think we could create a separate testing-pax module (or similar) where we
> just collect useful stuff for using pax
+1
-Bertrand
Re: Generalising Pax Exams
Posted by Carsten Ziegeler <cz...@apache.org>.
I think we could create a separate testing-pax module (or similar) where we
just collect useful stuff for using pax
Carsten
2013/4/12 Ian Boston <ie...@tfd.co.uk>
> That sounds better, inheritance was so JUnit 3.
> If I get a moment I might give it a go.
> Ian
>
>
> On 12 April 2013 16:41, Bertrand Delacretaz <bd...@apache.org>
> wrote:
>
> > hi Ian,
> >
> > On Fri, Apr 12, 2013 at 1:40 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> > > ...Last year I wrote [1] to make it simple to do Pax Exams, used by
> [2].
> > > Could/should this be made more generally available ? It fits mid way
> > > between a mocked test and a full blown IT....
> >
> > I like it, +1 for having this in Sling.
> >
> > Maybe the AbstractOSGiRunner could be a helper class instead of a base
> > class?
> >
> > Roughly something like
> >
> > @RunWith(PaxExam.class) // that's the new way with pax 3.x, see
> > installer/it
> > class MyTest // extends nothing {
> > final String artifactName = "foo";
> > final String [] imports = { "org.apache.sling.commons.cache.api" };
> > OSGiTestHelper helper = new OSGiTestHelper(artifactName, imports);
> >
> > @ProbeBuilder
> > public TestProbeBuilder _extendProbe(TestProbeBuilder builder) {
> > return helper._extendProbe(builder);
> > }
> >
> > @Configuration
> > public Option[] configuration() {
> > ...return composite of helper + my options
> > }
> >
> > @Test...
> > }
> >
> > The amount of boilerplate is similar, it's clearer IMO that the tests
> > are "talking" to pax exam and the helper doesn't take over the
> > inheritance chain.
> >
> > (I haven't tried if that would work though :-)
> >
> > -Bertrand
> >
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Generalising Pax Exams
Posted by Ian Boston <ie...@tfd.co.uk>.
That sounds better, inheritance was so JUnit 3.
If I get a moment I might give it a go.
Ian
On 12 April 2013 16:41, Bertrand Delacretaz <bd...@apache.org> wrote:
> hi Ian,
>
> On Fri, Apr 12, 2013 at 1:40 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> > ...Last year I wrote [1] to make it simple to do Pax Exams, used by [2].
> > Could/should this be made more generally available ? It fits mid way
> > between a mocked test and a full blown IT....
>
> I like it, +1 for having this in Sling.
>
> Maybe the AbstractOSGiRunner could be a helper class instead of a base
> class?
>
> Roughly something like
>
> @RunWith(PaxExam.class) // that's the new way with pax 3.x, see
> installer/it
> class MyTest // extends nothing {
> final String artifactName = "foo";
> final String [] imports = { "org.apache.sling.commons.cache.api" };
> OSGiTestHelper helper = new OSGiTestHelper(artifactName, imports);
>
> @ProbeBuilder
> public TestProbeBuilder _extendProbe(TestProbeBuilder builder) {
> return helper._extendProbe(builder);
> }
>
> @Configuration
> public Option[] configuration() {
> ...return composite of helper + my options
> }
>
> @Test...
> }
>
> The amount of boilerplate is similar, it's clearer IMO that the tests
> are "talking" to pax exam and the helper doesn't take over the
> inheritance chain.
>
> (I haven't tried if that would work though :-)
>
> -Bertrand
>
Re: Generalising Pax Exams
Posted by Bertrand Delacretaz <bd...@apache.org>.
hi Ian,
On Fri, Apr 12, 2013 at 1:40 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> ...Last year I wrote [1] to make it simple to do Pax Exams, used by [2].
> Could/should this be made more generally available ? It fits mid way
> between a mocked test and a full blown IT....
I like it, +1 for having this in Sling.
Maybe the AbstractOSGiRunner could be a helper class instead of a base class?
Roughly something like
@RunWith(PaxExam.class) // that's the new way with pax 3.x, see installer/it
class MyTest // extends nothing {
final String artifactName = "foo";
final String [] imports = { "org.apache.sling.commons.cache.api" };
OSGiTestHelper helper = new OSGiTestHelper(artifactName, imports);
@ProbeBuilder
public TestProbeBuilder _extendProbe(TestProbeBuilder builder) {
return helper._extendProbe(builder);
}
@Configuration
public Option[] configuration() {
...return composite of helper + my options
}
@Test...
}
The amount of boilerplate is similar, it's clearer IMO that the tests
are "talking" to pax exam and the helper doesn't take over the
inheritance chain.
(I haven't tried if that would work though :-)
-Bertrand