On Mon, Jun 22, 2015 at 12:48 PM, Bertrand Delacretaz <[email protected]> wrote: > On Mon, Jun 22, 2015 at 11:33 AM, Robert Munteanu <[email protected]> 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
