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 <[email protected]> wrote: > > Hi Konrad, > > On Tue, Sep 29, 2015 at 1:10 PM, Konrad Windszus <[email protected]> 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
