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
