Hi, I started https://cwiki.apache.org/confluence/display/SLING/Testing+Options to try to lay out these options.
Please update as necessary. Justin On Fri, Jan 24, 2014 at 9:33 AM, Bertrand Delacretaz <[email protected]> wrote: > Hi Justin, > > On Fri, Jan 24, 2014 at 3:09 PM, Justin Edelson > <[email protected]> wrote: >> ...Including this, we have three different ways of performing integration >> tests: >> 1) Externally running tests making HTTP calls against a running Sling >> instance (in some cases with test services deployed) >> 2) JUnit running inside Sling, with the results delivered to either a >> browser or JUnit client. >> 3) Sling running inside Pax Exam.... > > Granted, and I understand that choosing between #2 and #3 is not obvious. > > I don't have a firm answer at this point but my idea with this new > sling-pax-utils module [1] is to make it very easy to write tests in a > "modern" way, that run against a full Sling launchpad instance, with > minimal boilerplate in the tests and in the module's pom. While > keeping the full flexibility of pax exam, and being easier to debug in > an IDE than #2. > > Those tests should also be a bit faster than testing against a full > Sling instance via http which is #2, the most recent example of that > being the /extensions/models/integration-tests module after > yesterday's changes. > > OTOH, sling-pax-utils is not an exact Sling launchpad instance, so > there might be some edge cases where that's not sufficient. > > So at this point my suggestion would be to try and make > sling-pax-utils our default, while keeping #2 available for cases > where we really need a full remote Sling launchpad instance. I've only > used sling-pax-utils in contrib/extensions/i18n so far, so we'll > probably discover a few bugs along the way. > > -Bertrand > > [1] http://sling.apache.org/documentation/pax-exam-utils.html > [2] > https://svn.apache.org/repos/asf/sling/trunk/testing/sling-pax-util/src/test/java/org/apache/sling/paxexam/util/SlingRepositoryTest.java
