[ 
https://issues.apache.org/jira/browse/SLING-5352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048677#comment-15048677
 ] 

Bertrand Delacretaz commented on SLING-5352:
--------------------------------------------

bq. I am not happy that the patch requires setting both a @ClassRule and a 
@Rule.

Ah of course, if that's the case that's not good.

>From my point of view this is definitely an optimization and I'm not sure if 
>that's needed. Looking at the {{testing/samples/bundle-with-it}} module for 
>example:

{code}
Running org.apache.sling.testing.samples.bundlewit.ResourceMimeTypeDetectorIT
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.085 sec - in 
org.apache.sling.testing.samples.bundlewit.ResourceMimeTypeDetectorIT
{code}

That's 85 msec to execute two teleported tests on my 2 years old laptop, 
including the creation, installation, waiting and removal of two test bundles. 
Doesn't look like a problem to me, unless the test bundles are huge which would 
be a bad sign anyway.

So although creating a bundle for each test is not optimal, it doesn't seem to 
be an actual problem - I'd be open to improving that providing there are no 
downsides at all, and from my previous tests it looks like a ClassRule would 
confuse Eclipse when running tests from that IDE. Happy to be proven wrong (in 
code ;-)

> TeleporterRule should also work as a ClassRule
> ----------------------------------------------
>
>                 Key: SLING-5352
>                 URL: https://issues.apache.org/jira/browse/SLING-5352
>             Project: Sling
>          Issue Type: Improvement
>          Components: Testing
>    Affects Versions: JUnit Tests Teleporter 1.0.4
>            Reporter: Thierry Ygé
>         Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
>     @Rule
>     public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
>     @ClassRule
>     public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
>     @Rule
>     public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to