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

Bertrand Delacretaz edited comment on SLING-4541 at 6/8/15 12:04 PM:
---------------------------------------------------------------------

I have committed Petr's PathEntryTest in revision 1684130 and the 
DefaultContentCreatorTest extensions in revision 1684135, thanks!

For the createNode() test I agree that we're reaching the limits of where 
mocking makes sense - I have added a new CreateNodeTest in revision 1684164, 
using the RepositoryProvider to run tests on an actual JCR repository (which is 
the next level of testing as per [1]). This makes the tests much more natural 
IMO, at the expense of a longer test execution time but that's not too bad if 
several tests use this, the repository will be initialized just once. 
[~petr.shypila] please check if this would help in your case and feel free to 
reorganize all the tests once you dig deeper in this (or [~rombert] did you say 
you have something nicer using Sling Mocks?).

The createNode() coverage is far from complete with that new test, I just 
wanted to show how to use a real repository in tests.

I had to change the jackrabbit-api dependency version from 2.0.0 to 2.2.0, 
which changes the below imports. I don't think that's a problem as 2.0.0 is a 
very old version, this bundle will be incompatible with old systems that still 
use that but I don't think that's a problem.

import-package changes:
{code}
from
org.apache.jackrabbit.api.security.principal;version="[2.0,3)",
org.apache.jackrabbit.api.security.user;version="[2.0,3)"

to
org.apache.jackrabbit.api.security.principal;version="[2.2,3)",
org.apache.jackrabbit.api.security.user ;version="[2.2,3)"
{code}

[1] 
https://sling.apache.org/documentation/tutorials-how-tos/testing-sling-based-applications.html


was (Author: bdelacretaz):
I have committed Petr's PathEntryTest in revision 1684130 and the 
DefaultContentCreatorTest extensions in revision 1684135, thanks!

For the createNode() test I agree that we're reaching the limits of where 
mocking makes sense - I have added a new CreateNodeTest in revision 1684164, 
using the RepositoryProvider to run tests on an actual JCR repository (which is 
the next level of testing as per [1]). This makes the tests much more natural 
IMO, at the expense of a longer test execution time but that's not too bad if 
several tests use this, the repository will be initialized just once. 
[~petr.shypila] please check if this would help in your case and feel free to 
reorganize all the tests once you dig deeper in this (or [~rombert] did you say 
you have something nicer using Sling Mocks?).

I had to change the jackrabbit-api dependency version from 2.0.0 to 2.2.0, 
which changes the below imports. I don't think that's a problem as 2.0.0 is a 
very old version, this bundle will be incompatible with old systems that still 
use that but I don't think that's a problem.

import-package changes:
{code}
from
org.apache.jackrabbit.api.security.principal;version="[2.0,3)",
org.apache.jackrabbit.api.security.user;version="[2.0,3)"

to
org.apache.jackrabbit.api.security.principal;version="[2.2,3)",
org.apache.jackrabbit.api.security.user ;version="[2.2,3)"
{code}

[1] 
https://sling.apache.org/documentation/tutorials-how-tos/testing-sling-based-applications.html

> Provide an extensive test suite for the JCR content loader
> ----------------------------------------------------------
>
>                 Key: SLING-4541
>                 URL: https://issues.apache.org/jira/browse/SLING-4541
>             Project: Sling
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: JCR ContentLoader 2.1.10
>            Reporter: Radu Cotescu
>            Assignee: Petr Shypila
>             Fix For: JCR ContentLoader 2.2.0
>
>         Attachments: week2-part1-pathentry.patch, 
> week2-part2-defaultcontentcreator.patch, week2-part3-single-jcrmock-test.patch
>
>
> The JCR content loader is a sensible bundle. An extensive IT suite should be 
> written to make sure that code changes don't affect core functionality.



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

Reply via email to