Hi, Thanks everyone for having a look and thanks for the 2 +1s. One more would be needed for a release. Can anybody else take a look? @Daniel, did it work for you?
Thanks a lot! - Andrei On Wed, Sep 21, 2016 at 10:34 AM Andrei Dulvac <andrei.dul...@gmail.com> wrote: > Sorry, I forgot I had already added > https://sling.apache.org/documentation/tutorials-how-tos/testing-sling-based-applications.html#http-based-integration-tests > > Would it make sense to add it to the page you linked and maybe drop a > couple of lines regarding the usecases? > > - Andrei > > > On Wed, Sep 21, 2016 at 10:31 AM Andrei Dulvac <dul...@apache.org> wrote: > >> Hi Konrad, >> >> On Wed, Sep 21, 2016 at 10:18 AM Konrad Windszus <konra...@gmx.de> wrote: >> >>> Hey Andrei, could you briefly mention those new bundles in >>> https://sling.apache.org/documentation/development/sling-testing-tools.html >>> and/or >>> https://sling.apache.org/documentation/bundles/org-apache-sling-junit-bundles.html >>> just to have the complete picture on those pages? >>> >> >> Yes, I'll update those pages. Might take a while, as I'm still learning >> the ways of the apache CMS and all that. >> >> >>> >>> To me the difference to the Teleporter approach is not that obvious. >>> Maybe you can write some sentences on when it is recommended to choose >>> which approach. >>> >> >> Hmm, I think there are almost NO collisions there. >> >> The teleporter is a brilliant mechanism that runs a test on both the >> client-side (but only what's going on before the teleporter rule swaps the >> junit statement with a bundle creation, upload and test trigger on the >> server) and on the server-side, using sling junit core. You write tests on >> the serverside, but trigger them from the client-side and report them on >> the client-side. >> >> The Sling HTTP testing clients/ rules are a toolset of HTTP/ Junit >> goodies for writing tests that interact with instances at HTTP level. Think >> that you'd wanna test a servlet or a jsp. It would be a bit weird to do >> that from a server-side test written with the teleporter. >> >> Or that you want to test some clustering functionality where you have/ >> provision 3 instances and interact with them "from the top" and the test >> logic needs 3 instances (see *SlingInstanceRule*). If you write a test >> with the teleporter, it will run *inside* one instance. >> >> Or that you want to use the clients in a stress-testing scenario (we're >> using the http clients in an internal tool in Adobe to stress test the >> system with Sling-specific operations, like creating and deleting nodes). >> The client-side junit stays stable and can keep going if the server is >> unresponsive. >> >> Also, you can perfectly have a module with some tests using the http >> framework and some tests using the teleporter. >> >> I hope this makes sense and that I haven't misunderstood the question. >> >> - Andrei >> >> >>> >>> Thanks, >>> Konrad >>> >>> > Am 21.09.2016 um 10:11 schrieb Andrei Dulvac <dul...@apache.org>: >>> > >>> > Hi Stefan. >>> > Thanks for the +1. >>> > On Tue, Sep 20, 2016 at 6:20 PM Stefan Seifert <sseif...@pro-vision.de >>> > >>> > wrote: >>> > >>> >> +1 >>> >> >>> >> this is a lot of interesting stuff - do we already have some >>> >> documentation/sample project for this? >>> >> >>> > We have some docu on the junit rules [0] - the entrypoint for writing a >>> > test, some docu on the clients [1] (the FAQ at the end also provides >>> some >>> > insight into some design choices). >>> > >>> > I've also adapted the old SlingTestBase from sling.testing.tools in >>> > serversetup [2] in order to use those in the sling tests, using the >>> > existing mechanism to start a new sling instance for tests, as part of >>> the >>> > maven build. It's used in the SlingInstanceRule [3] which I used to >>> adapt >>> > some sample tests like [4] (I didn't want to touch launchpad tests or >>> > anything like that, but I'm willing to put in some work if needed). I >>> see >>> > Bertrand also adapted some tests there, in samples/ lately. >>> > >>> > That's mostly what we have, no wholesome documentation, unfortunately. >>> Ah, >>> > another helpful thing to have a look at is the unit tests for the >>> clients, >>> > like AbstractSlingClientGetUrlTest [5] which makes sure there are no >>> > regressions in terms of how URIs are dealt with. >>> > >>> > HTH, >>> > - Andrei >>> > >>> > --- >>> > [0] https://github.com/apache/sling/tree/trunk/testing/junit/rules >>> > [1] https://github.com/apache/sling/tree/trunk/testing/http/clients >>> > [2] >>> > >>> https://github.com/apache/sling/blob/trunk/testing/serversetup/src/main/java/org/apache/sling/testing/serversetup/instance/SlingTestBase.java >>> > [3] >>> > >>> https://github.com/apache/sling/blob/trunk/testing/junit/rules/src/main/java/org/apache/sling/testing/junit/rules/SlingInstanceRule.java >>> > [4] >>> > >>> https://github.com/apache/sling/blob/b0debb458d0ac7098ded772412adc11163865d2c/testing/samples/bundle-with-it/src/test/java/org/apache/sling/testing/samples/bundlewit/OsgiConsoleHttpIT.java >>> > [5] >>> > >>> https://github.com/apache/sling/blob/trunk/testing/http/clients/src/test/java/org/apache/sling/testing/AbstractSlingClientGetUrlTest.java >>> >>>
