Alexander Klimetschek wrote: > The jcr resource resolver used must be a real one and not a mock > object! The thing about the SlingTestHelper is that it makes your life > easier by working in a way not requiring an osgi framework running in > the unit test. That requires some tricks (incl. access to internal > packages), because configuration for most objects can normally only be > provided via osgi config. Same for the AdapterManagerTestHelper (still > in commons/testing, but part of the SlingTestHelper code from the > SLING-1166 patch). I already changed the test in the i18n bundle to use a mocked object. And it works as only two methods of the resolver are used.
> > A better solution (w/o requiring unit tests to run a osgi framework) > could be that those bundles make such a usage simpler, w/o having to > depend on internal classes. But using internal packages for unit > testing is IMO ok (and merely a blocker, because IDE test runners such > as in Eclipse or the maven surefire plugin use the full jars for the > classpath anyway and do not use the osgi bundle header). Using internal classes of other bundles will create a problem over time. > Also, these tests are intended to be used by non-Sling code. I moved > them over from our product (cq5) where they are used for quite a few > unit tests. The unit tests still use the original code in the product, > but I wanted to switch over to the Sling variant and drop that old > code. > > I would keep them split. The question is what commons.testing is > about? Is it mainly for making it easier to write tests for sling core > bundles? In that case we definitely have a circular dependency and > must keep both split. Otherwise we can merge them and move them out. > The SlingTestHelper itself should never grow to have more dependencies > than just that of the (few) core bundles. > All bundles in commons are well common stuff which is not tied to sling at all. As we have sling specific stuff in it, it doesn't fit in the commons category. So the purpose of this bundle is indeed to make writing sling tests easier. But I think we should not create more and more classes for problems that could be solved in another way much easier. For example, the patch added some mock classes to the adapter package whereas the bundle already had mock classes for this stuff. The TestHelper uses an internal package name which seems odd as well. And I really would apply YAGNI - the new stuff added is only partially used in Sling itself. I would say go with simple unit tests where you can work with mock objects. If you need a full blown resource resolver, just use pax exam, fire up an osgi framework and start the jcr bundle. It's really easy to do this. Carsten -- Carsten Ziegeler cziege...@apache.org
