Hi Petr I'm mostly guessing, so YMMV.
Your test imports "org.apache.sling.jcr.contentloader.internal.*". By convention the maven-bundle-plugin treats "impl" and "internal" packages as private, i.e. they are not exported. Now you're building a PaxExam test, where OSGi semantics are respected. Therefore the classes are not accessible (as designed). If you can write your tests in Sling Mocks you should not suffer the same issue, as they use a conventional java classpath. I'm wondering what you are trying to test? Does it make sense to test internals on an OSGi level? Or could you test the internals using standard unit tests? Regards Julian On Mon, Jun 22, 2015 at 3:02 PM, Petr Shypila <ikrump...@gmail.com> wrote: > Thanks for everyone. > > So as I understand for now Sling Mocks is the preferable and most modern > way to write unit tests. Is that correct? > What about JCR data store? Does it save data between tests and should take > care of that? > > A question about PaxExam. Right now I have problems with > BundleContentLoader initialization. Every time I getting > ClassNotFoundException. > I have added a patch with an example. Could you please take a look and > write me what I'm doing wrong? > > Thank you very much, > Petr > > https://www.dropbox.com/s/8k7v7houbynom6k/PaxExam-ClassNotFoundException.patch?dl=0 > > 2015-06-22 13:03 GMT+03:00 Robert Munteanu <romb...@apache.org>: > >> On Mon, Jun 22, 2015 at 12:48 PM, Bertrand Delacretaz >> <bdelacre...@apache.org> wrote: >> > On Mon, Jun 22, 2015 at 11:33 AM, Robert Munteanu <rob...@lmn.ro> wrote: >> >> ...It would be interesting to see >> >> what testing scenario you had in mind and how to better address it - >> >> whether it's Sling mocks or Pax-Exam or something different.... >> > >> > Yes, I agree that discussing this on a very concrete case would help, >> > and Petr's intensive work on testing is a good opportunity to come up >> > with best practices around that. >> > >> > My comments on SLING-4541 where based on testing the >> > (bundles/jcr/contentloader) ContentLoaderService's handling of >> > incoming and updated bundles: it needs to register incoming bundles >> > which supply initial content, and correctly handle updates to those >> > bundles. >> > >> > Testing this is quite natural in a real OSGi environment, though I >> > agree that that runs slows that unit or mocked tests of course. >> > >> > Robert, do you think this can be tested in a valid and understandable >> > way using mocks? >> >> Looking at ContentLoaderServiceTest.testBundleResolvedBundleChanged it >> looks like a perfect example of using Pax-Exam - it relies too much on >> the OSGi framework properly creating bundle objects and issuing events >> and too little on the Sling / JCR infrastructure. >> >> IMO if a test uses only OSGi ( and not the JCR or Sling APIs ) and >> does so beyond simple API usage that can be easily served by the OSGi >> mocks then it should use Pax-Exam. >> >> The value for the Sling Mocks comes in when either using a large part >> of our stack - it's convenient for OSGi + JCR tests for instance. >> >> > Setting up pax exam is quite easy using our testing/sling-pax-util >> > module for example (but we should convert that module to use the Sling >> > provisioning model now). >> >> Speed of setting up an OSGi container is not a major concern for me >> when writing Pax-Exam tests, but rather all the scaffolding needed to >> get the container up and running, and then keeping it in sync with the >> 'latest' bundles. sling-pax-util looks like it goes a long way in >> simplifying that setup , which is great. >> >> What I also see as a blurry line is when to write a Pax-Exam test >> which uses the repository and when to write a full-fledged integration >> test. That's also something to discuss as we have different approaches >> throughout the codebase, but perhaps for later :-) >> >> Cheers, >> >> Robert >> >> > -Bertrand >>
