Hi Bertrand, While I agree that promoting pax-exam-utils is the right way to go if we're going to have modules like i18n depending upon it, I'm a little concerned that we're making the testing situation more complex for our users when we should IMHO be doing the opposite.
Including this, we have three different ways of performing integration tests: 1) Externally running tests making HTTP calls against a running Sling instance (in some cases with test services deployed) 2) JUnit running inside Sling, with the results delivered to either a browser or JUnit client. 3) Sling running inside Pax Exam. Whereas the difference between #1 and #2 is somewhat clear (black box vs. white box testing), #2 and #3 look very similar to me (possibly I'm missing something) and I'm honestly not sure when I would pick one over the other. How can we articulate the difference between #2 and #3 in such a way that our users (let alone us) have the information necessary to make an educated choice when writing tests? Regards, Justin On Fri, Jan 24, 2014 at 5:12 AM, Bertrand Delacretaz <[email protected]> wrote: > Hi, > > On Fri, Jan 24, 2014 at 8:57 AM, Felix Meschberger <[email protected]> wrote: >> ...From the name and usage in i18n (and probably others), I would assume >> this is some testing support stuff. >> Shoudn't that rather be in the testing root folder ?... > > Good idea - I'll move it there. > > The goal of that module is to make it very simple to test your code in > a full Sling launchpad environment. > >> ...And can we have a release of this ? Otherwise consumer bundles cannot be >> released….. > > Yeah, releasing that has been on my list for way too long, I'll > prepare a release today. > > -Bertrand
