Hi, the TeleporterRule-based tests look indeed much cleaner and leaner than with the old approach. But I was wondering whether it would be good to extend the teleporter module with some customizer rules which would allow to run the test on an already provisioned instance. Currently we only have the customizer available in https://github.com/apache/sling/tree/trunk/launchpad/integration-tests <https://github.com/apache/sling/tree/trunk/launchpad/integration-tests>, but the integration tests for Sling Models reside in https://github.com/apache/sling/tree/trunk/bundles/extensions/models/integration-tests <https://github.com/apache/sling/tree/trunk/bundles/extensions/models/integration-tests>. What about a customizer which can be parameterised equally to the former SlingTestBase (http://labs.6dglobal.com/blog/2013-06-05/creating-integration-tests-apache-sling/ <http://labs.6dglobal.com/blog/2013-06-05/creating-integration-tests-apache-sling/>)? The requirements for such a customizer are IMHO: - customizable base URL - customizable credentials - optionally deploys additional dependencies - debug option
WDYT? Konrad > On 23 Sep 2015, at 16:58, Bertrand Delacretaz <[email protected]> wrote: > > Hi, > > FYI I have created a new docs page at > > http://sling.apache.org/documentation/bundles/org-apache-sling-junit-bundles.html > > which replaces this one, which is now mostly obsolete: > > https://sling.apache.org/documentation/development/sling-testing-tools.html > > I have created a TeleporterRule, described on the new docs page, which > makes it much easier to create server-side tests. It's using the same > JUnitServlet-based mechanism as before, but the low-level details of > that are now hidden from the user. > > Feedback is welcome of course, for now I have converted/created a > number of tests that use the TeleporterRule under > launchpad/integration-tests, and it seems to work fine. > > -Bertrand
