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
> 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
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 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
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.
> > 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  - the entrypoint for writing a
> > test, some docu on the clients  (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  in order to use those in the sling tests, using the
> > existing mechanism to start a new sling instance for tests, as part of
> > maven build. It's used in the SlingInstanceRule  which I used to adapt
> > some sample tests like  (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.
> > another helpful thing to have a look at is the unit tests for the
> > like AbstractSlingClientGetUrlTest  which makes sure there are no
> > regressions in terms of how URIs are dealt with.
> > HTH,
> > - Andrei
> > ---
> >  https://github.com/apache/sling/tree/trunk/testing/junit/rules
> >  https://github.com/apache/sling/tree/trunk/testing/http/clients
> > 
> > 
> > 
> >