You're right, Thierry. There is even a comment to this effect in ClientSideTeleporter.
I agree though, that having this as a ClassRule may be useful. Regards Julian On Thu, Dec 3, 2015 at 2:27 PM, Thierry Yge <[email protected]> wrote: > Actually the real error I have is: > > java.lang.Exception: No tests found matching Method > null(com.adobe.cq.platform.security.it.serverside.TestClassRuleSST) from > org.junit.internal.requests.ClassRequest@42fcda97 > > at > org.junit.internal.requests.FilterRequest.getRunner(FilterRequest.java:35) > > at org.junit.runner.JUnitCore.run(JUnitCore.java:138) > > at > org.apache.sling.junit.impl.TestsManagerImpl.executeTests(TestsManagerImpl.java:199) > > at > org.apache.sling.junit.impl.servlet.ServletProcessor.doPost(ServletProcessor.java:158) > > at > org.apache.sling.junit.impl.servlet.JUnitServlet.doPost(JUnitServlet.java:103) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:644) > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:725) > > > The previous error was due to missing Customizer class. > > -Thierry > > 2015-12-03 14:12 GMT+01:00 Thierry Yge <[email protected]>: > >> It doesn't work, I think you mean something like that ? >> >> {code} >> package x.y.z; >> >> import org.slf4j.Logger; >> >> import org.slf4j.LoggerFactory; >> >> import org.apache.sling.junit.rules.TeleporterRule; >> >> import org.junit.ClassRule; >> >> import org.junit.Test; >> >> >> public class TestClassRuleSST { >> >> >> >> private static final Logger LOG = >> LoggerFactory.getLogger(TestClassRuleSST.class); >> >> >> >> @ClassRule >> >> public static TeleporterRule teleporter = >> TeleporterRule.forClass(TestClassRuleSST.class, "Launchpad"); >> >> >> >> @Test >> >> public void testTest1() { >> >> LOG.info("test1 run"); >> >> } >> >> >> @Test >> >> public void testTest2() { >> >> LOG.info("test2 run"); >> >> } >> >> >> } >> >> {code} >> >> It fails to run due to : >> >> java.lang.RuntimeException: Unable to instantiate >> org.apache.sling.junit.teleporter.customizers.LaunchpadCustomizer >> >> at >> org.apache.sling.junit.rules.TeleporterRule.createInstance(TeleporterRule.java:123) >> >> >> I am not sure that TeleporterRule was meant to be run as a ClassRule , >> that is why I think it isn't as simple unfortunately to run all the test >> with a one time tiny bundle creation / installation per test class. >> >> Regards, >> >> -Thierry >> >> >> >> 2015-12-03 13:46 GMT+01:00 Julian Sedding <[email protected]>: >> >>> Hi Thierry >>> >>> TeleporterRule extends ExternalResource >>> ExternalResource implements TestRule >>> >>> From the documentation of TestRule[0]: >>> - "[...] TestRules can do everything that could be done previously >>> with methods annotated with Before, After, BeforeClass, or AfterClass, >>> [...]" >>> - "[...] Rule annotates method-level TestRules, and ClassRule >>> annotates class-level TestRules. [...]" >>> >>> Why don't you give it a try?! And then report back whether it worked ;) >>> >>> Regards >>> Julian >>> >>> [0] http://junit.org/javadoc/latest/org/junit/rules/TestRule.html >>> >>> On Thu, Dec 3, 2015 at 11:58 AM, Thierry Yge <[email protected]> >>> wrote: >>> > Hi Julian, >>> > >>> > currently the teleporter is a method rule, so that is the point, maybe >>> we >>> > need a teleporter rule that also applies at classrule level. >>> > >>> > Or maybe I am wrong here :) >>> > >>> > Regards, >>> > -Thierry >>> > >>> > On Thu, 3 Dec 2015, 10:17 a.m. Julian Sedding <[email protected]> >>> wrote: >>> > >>> >> Hi Thierry >>> >> >>> >> I haven't tried it, but would imagine that annotating the rule with >>> >> @ClassRule should do the trick? >>> >> >>> >> Regards >>> >> Julian >>> >> >>> >> On Thu, Dec 3, 2015 at 9:44 AM, Thierry Yge <[email protected]> >>> wrote: >>> >> > Hi Bertrand, >>> >> > >>> >> > I see that the TeleporterRule always create the same package, and at >>> the >>> >> > end if you have multiple test in the same test class (which is >>> usually >>> >> the >>> >> > case), and so eachtime it run a test from that class, it does create >>> the >>> >> > tinybundle , send / install it on target sling instance, run the >>> test and >>> >> > uninstall the bundle etc... >>> >> > >>> >> > That is a lot of round trip. Is there a way to instruct the >>> Teleporter to >>> >> > do the tinybundle like in a "before class", and then run the test as >>> >> usual, >>> >> > then uninstall only at the end of the test ? >>> >> > >>> >> > At least if we could limit the number of round trip that would be >>> nice, >>> >> to >>> >> > improve tests execution time. >>> >> > >>> >> > Any idea if that is already possible to achieve ? >>> >> > >>> >> > Best regards, >>> >> > -Thierry >>> >> >>> >> >>
