On Tue, Nov 17, 2009 at 16:56, Carsten Ziegeler <cziege...@apache.org> wrote: > 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.
Ok, I have seen the change. That's ok for sling i18n. I wrote the slingtesthelper before the i18n tests, with the requirement of a full resolver at hand. > Using internal classes of other bundles will create a problem over time. Agreed, but it was the simplest solution. > 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. Agreed. I just added the code to the one existing test helper bundle initially. > 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. The reason were package protected methods. > 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. How fast is it? Can you provide an example? The nice thing about my approach is that I can selectively create the objects I need. A pax based solution should allow the same. Having to activate every component, even those that aren't tested at all, can slow down things. However, as the i18n module no longer requires slingtest, and nobody likes this, I think a veto on SLING-1166 is required and you can drop it. My aim with this was to make it easier to write unit tests this way. My fear is that requiring an additional framework (pax) for unit tests (dependencies ++) increases the burden for writing unit tests at all. Regards, Alex -- Alexander Klimetschek alexander.klimetsc...@day.com
