Hi, On Mon, Nov 16, 2009 at 9:59 AM, Carsten Ziegeler <cziege...@apache.org> 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. > 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. 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. > ...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. > 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? > 5. o.a.s.c.testing.sling > Mocks for some sling apis - again, I see no need for explicit mock classes. Same as above > 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. > The relevant stuff dealing with Sling specific test helpers can then be > moved into the new module. Agreed. -Bertrand
