I created https://issues.apache.org/jira/browse/SLING-5677 on the proposal from below.
One open question after looking at the code is: Why is the customize() method part of the TeleporterRule instead of the ClientSideTeleporter? I don't see that the customize() is useful for the server-side execution at all. So I would recommend to just move it. > On 21 Apr 2016, at 15:23, Konrad Windszus <konra...@gmx.de> wrote: > > 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 >> >
