On Thu, Apr 21, 2016 at 3:23 PM, Konrad Windszus <[email protected]> wrote:
> 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) Agreed, that's a pity. Maybe you can improve the example to use the slingstart plugin instead? > 2) Is of packaging "bundle" for whatever reason. >From the sample project's pom: "Sample project that demonstrates a bundle with unit and integration tests in the same Maven module, running against a full Sling instance." IIUC the goal was to maintain the integration tests together with the bundle under test. Regards Julian > > > 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 <[email protected]> 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 <[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 >> >
