Bertrand Delacretaz wrote: > Hi, > > On Mon, Nov 16, 2009 at 9:59 AM, Carsten Ziegeler <[email protected]> > wrote: >> I've looked at our commons testing again, and personally I'm not sure if >> we need most of the stuff anyway :) >> >> Let's have a look at the packages: >> 1. o.a.s.adapter.internal >> >> Helper stuff if you're using adapter managers. If this has some common >> interest we could move this to the sling testing module. > > Did you check if it's currently used somewhere? > If not, ok to remove it. Strangely this is just used in the new slingtest module....so it seems we can remove it "somehow" (or merge it into slingtest)
> >> 2. o.a.s.c.testing.integration >> Some http stuff which is only of interest for integration testing. >> Doesn't really hurt, but there is rarely interest in plain junit tests. > > I created the commons/testing module to support our integration test > modules and hopefully help people do integration testing, so those > classes do belong somewhere. Yes, sure - and that's a good thing! > If you want to move them to a separate integration-testing module I'm > fine with that, but personally I don't care much about the distinction > between "pure" JUnit testing and integration testing. Yepp, I was thinking along the same lines, maybe it's not worth separating it know, but it might over time if this stuff gets bigger. > >> ...3. o.a.s.c.testing.jcr >> Some Mock classes for JCR and the RepositoryUtil - I think this class is >> great for doing JCR based tests - however I think this is something >> Jackrabbit should provide us!.. > > If you want to donate/move that to Jackrabbit I'm fine. I'll try > >> In addition we currently have a dependency to Sling API here, so we have >> to split it anyway. > > right > >> 4. o.a.s.c.testing.osgi >> Just mocks for some OSGi interfaces - I see no need for these as mock >> libs like jmock or easymock can be used instead. > > I assume those classes are used in existing code, did you check the > impact on removing them? Afaik, they are used - they could be easily replaced, but I think we can remove these without removing its usage :) The testing bundle is released, so if people want to use it they can use the latest release. A newer version won't have these anymore. And I would replace the usage in our sling code base over time. >> 5. o.a.s.c.testing.sling >> Mocks for some sling apis - again, I see no need for explicit mock classes. > > Same as above Yepp. > >> 6. o.a.s.c.testing.util >> A single class with a single String method that replaces "\n" with a >> dot. Don't think that this is of general use - it is only used in the >> jst bundle atm, so we should rather move it there. > > Right, if it's only used there that makes sense. > >> As a conclusion I think we don't need a commons testing module, given >> the fact that jackrabbit would provide us a repository util class that >> can easily be used for testing - I think this makes sense to be provided >> by Jackrabbit for all possible clients of Jackrabbit not just sling. > > I want the integration testing helpers to stay, but as indicated I'm > not against changing the name of the module that supplies them. Yes, makes sense. Thanks Carsten > >> The relevant stuff dealing with Sling specific test helpers can then be >> moved into the new module. > > Agreed. > > -Bertrand > -- Carsten Ziegeler [email protected]
