On Mon, 2015-06-22 at 14:58 +0200, Bertrand Delacretaz wrote: > Hi Robert, > > On Mon, Jun 22, 2015 at 12:03 PM, Robert Munteanu <romb...@apache.org > > wrote: > > ...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.... > > Ok, sounds good to me as a guideline - we might refine > http://sling.apache.org/documentation/tutorials-how-tos/testing-sling > -based-applications.html > with such guidelines as Petr's project progresses. > > > ...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... > > Yes, the only drag is that if it refers to a snapshot of the bundle > list that it uses (usually launchpad) which is suboptimal. We might > move the launchpad's provisioning model to its own module to be able > to release it more often, so that tests can refer to those releases.
By the provisioning model do you mean launchpad/builder/src/main/provisioning [2]? I have been thinking about how we can reuse that data so we can have more stable building blocks for tests and other applications ; out of the current features - boot and standalone are probably quite stable and can be used moved into separate artifacts - jackrabbit and oak are in the middle area, updating every now and then based on upstream releases - sling is however quite fast-moving and I am not sure we can slow down the release pace with its current contents. Perhaps we can split the sling feature further? We have a section for JCR support [3], one for the web console [4] which look relatively self -contained. > > > > > ...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 :-)... > > As for full-fledged do you mean something under launchpad/integration > tests? My current thinking is to move integration tests closer to > their modules, as much as we can. Yes, full-fledged ITs are the ones living under launchpad/integration . And I definitely agree that ITs should live close to the modules they test. > > For example I recently added ContentAwareMimeTypeServiceImplIT. [1] > which runs with pax exam, has very little boilerplate code and does > not mess up the pom too much either, it just requires the pax > dependencies and some simple maven-failsafe-plugin configs there. I > think that's a nice way of adding integration tests right in their > modules, and with the SLING-4760 Jacoco setup you can easily get the > aggregate coverage of unit + integration tests. If we do that role of > the the launchpad/integration-tests is really only to check that the > assembly works, it doesn't have to go into detail anymore. +1 . At that point, with a fast-starting launchpad, we can even move the tests into the launchpad/builder project itself and rely on a `mvn clean verify` to assert that the bundles function correctly together. Robert [2]: https://github.com/apache/sling/tree/555c5204b1486c666d612cb9dee72 9b3f2c878fd/launchpad/builder/src/main/provisioning [3]: https://github.com/apache/sling/blob/555c5204b1486c666d612cb9dee72 9b3f2c878fd/launchpad/builder/src/main/provisioning/sling.txt#L105-L120 [4]: https://github.com/apache/sling/blob/555c5204b1486c666d612cb9dee72 9b3f2c878fd/launchpad/builder/src/main/provisioning/sling.txt#L77-L97 > > (BTW Petr [1] might be a good example if you want to move to pax exam > for some of your SLING-4541 tests - you can also create a prototype > that we can discuss if you prefer) > -Bertrand > > [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/commons/cont > entdetection/src/test/java/org/apache/sling/commons/contentdetection/ > internal/it/ContentAwareMimeTypeServiceImplIT.java
