Hi Bertrand,
I finally solved all problems which I had with this integration tests and
for now everything is clear for me.
Yesterday I was stuck for a while(because of my poor OSGi knowledge), but
as I wrote, now everything is fine.
So integration tests for this module will be presented.
The only problem I have now is JaCoCo report. It looks like it doesn't
creates reports for integration tests(Few weeks ago everything was fine). I
updated contentloader's parent to 24-SNAPSHOT(I tried 23-SNAPSHOT as well)
but it didn't help me.
<parent>
<groupId>org.apache.sling</groupId>
<artifactId>sling</artifactId>
<version>24-SNAPSHOT</version>
<relativePath/>
</parent>
<artifactId>org.apache.sling.jcr.contentloader</artifactId>
<version>2.1.11-SNAPSHOT</version>
<packaging>bundle</packaging>
I build module with this command: mvn clean install -Pjacoco-report.
2015-06-25 12:04 GMT+03:00 Bertrand Delacretaz <bdelacre...@apache.org>:
> Hi Petr,
>
> On Thu, Jun 25, 2015 at 9:40 AM, Petr Shypila <ikrump...@gmail.com> wrote:
> > ...I also got a look on other modules under ./bundles and it looks like
> engine
> > is a very good one, because it's coverage is only 20%(e.g.
> resourceresolver
> > coverage is 70%)....
>
> Both engine and resourceresolver are good candidates, as they are
> critical core bundles.
>
> I suspect that our launchpad integration tests also cover quite a bit
> of those modules, it might be nice to have a look at the aggregate
> coverage of (for example) the bundles/engine module based on both its
> own tests and on the launchpad/testing tests.
>
> I did experiment with generating that aggregate launchpad + local
> coverage in SLING-1803 (the integration-deploys-jacoco-exec.patch) in
> addition to SLING-4760. Once you're mostly done with the contentloader
> tests it might be good to look at this - if we can easily get that
> aggregate coverage that might help focus your efforts better. That
> patch is probably stale but we could reuse the general idea - having
> launchpad/testing deploy its coverage data to Maven so that other
> modules can merge it with their own coverage.
>
> > ...I see that most tests are written with
> > JMock. Could be there some other useful information for me how to test
> this
> > module in better way?...
>
> I've been moving to Mockito lately, the code is more readable than
> JMock IMO. If a module has few tests so far you might switch it to
> Mockito for consistency. Maybe JMock has also improved in the
> meantime.
>
> -Bertrand
>
