Yep it worked, +1 from me! On Fri, Sep 23, 2016 at 6:07 AM, Andrei Dulvac <dul...@apache.org> wrote:
> 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/b0debb458d0ac7098ded772412adc1 > 1163865d2c/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 > >>> > >>> >
