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 <[email protected]> > 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 <[email protected]> > wrote: > > > hi Ian, > > > > On Fri, Apr 12, 2013 at 1:40 AM, Ian Boston <[email protected]> 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 [email protected]
