I would like to revive this old thread, because I now want to leverage the TeleporterRule. It would be great if someone could verify the following observations:
There are two customizers available: a) The LaunchpadCustomizer, which only verifies that a Sling instance is ready at a given port, and then that the ClientSideTeleporter will deploy the bundle to the right instance afterwards. LaunchpadCustomizer uses the HttpTestBase therefore some parameters are customizable through Maven Parameters (we should document them). There is no bootstrapping of an instance done here, so this must be done separately! b) The BWIT_TeleporterCustomizer, which is leveraging the SlingTestBase, therefore all properties described at http://labs.6dglobal.com/blog/2013-06-05/creating-integration-tests-apache-sling/ are available. It takes care of bootstrapping the Sling instance as well (so it is incompatible to use this together with slingstart-maven-plugin). For me neither a) nor b) are optimal. I would rather like to have no customizer at all (being referenced from the TeleporterRule), The bootstrapping of a new instance should IMHO always be outside of the Customizer and completely outside of the execution of maven-failsafe-plugin. Instead the slingstart-maven-plugin should be used (by default bound to pre-integration-test and post-integrationtest). The only customization being necessary is in most cases the ClientSideTeleporter.include/excludeDependencyPrefix. That I would rather like to parameterize through system properties! That way the actual test does not need to reference this. Also of course the URL of the target Sling server needs to be parameterized! So for me the optimal way developing ITs is the following 1) Create a new JAR (not bundle) 2) Leverage slingstart-maven-plugin to bootstrap and start Sling or just connect to an existing already running instance (only through pom.xml changes achievable) 3) Put the ITs in src/test/java and with the suffix IT 4) Let maven-failsafe-plugin execute the IT containing the TeleporterRule (which leads to deployment of the temp bundle containing the ITs) Unfortunately not even the example at https://github.com/apache/sling/tree/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/testing/samples/bundle-with-it shows such a setup. That for example 1) Still uses the SlingTestBase (through its own Customizer) 2) Is of packaging "bundle" for whatever reason. How do you feel about reworking the Teleporter, that this simple setup is supported without any Customizer at all? Thanks, Konrad > On 30 Sep 2015, at 13:38, Konrad Windszus <konra...@gmx.de> wrote: > > Hi Bertrand, > to me it is not clear what should be the obligation of the customizer and > what should be built into the ClientSideTeleporter. > For me the provisioning of the new instance or configuration of the existing > instance (on which the IT is executed) is core part of each integration test > (since either of those two are always necessary to run the ITs) > But I don’t want to have that configuration in the code but rather have that > configurable through Maven properties (like we used to do it with > SlingTestBase). > Therefore I don’t expect from a developer to specify in code, to which > instance to connect (and whether to spin up a new or use an existing one). > That should be changeable without touching the source code. > > So I would suggest the following: Make the ClientSideTeleporter usable > without any customizer and without any glue code but just with additional > system properties. > The system properties are then used to either connect to an existing instance > or to spin up a completely new instance (similar to what the SlingTestBase > does). > > If you agree I would try to come up with a patch for the ClientSideTeleporter > which adds the functionality of the SlingTestBase into it. > The existing customizers can then be removed most probably. > > Also I would suggest to move the Customizer interface from the JUnit-Core to > the Teleporter module (since it is called on client side only anyways). > WDYT? > > Regards > Konrad > > >> On 29 Sep 2015, at 13:17, Bertrand Delacretaz <bdelacre...@apache.org> wrote: >> >> Hi Konrad, >> >> On Tue, Sep 29, 2015 at 1:10 PM, Konrad Windszus <konra...@gmx.de> wrote: >>> What about a customizer which can be parameterised equally to the >>> former SlingTestBase... >> >> That's totally possible, the only requirement is that the junit.core >> bundle running on the server side must not require any knowledge from >> those classes, to avoid having to ship them to the server. Hence the >> current string-based customizer class selection. >> >> Providing a richer customizer would be great, ideally in a separate >> module so as to make it easy to use such teleported tests in any >> module, with minimal boilerplate required to setup the Sling instance >> under test. And that Sling instance can also be used for HTTP-based >> tests so we should probably unify the setup mechanisms. >> >> -Bertrand >
