Upayavira wrote:
I need to remove the test-suite and use samples/test, and confirm that Ugo's fixes have made the CocoonBeanTestCase work, and then re-enable it.

A word of caution. My fixes add the blocks directory and block-provided jars to the classpath for tests and make the "junit-tests" target depend upon the "blocks" target.


This is necessary because the CocoonBeanTestCase loads "build/webapp/WEB-INF/cocoon.xconf", which contains references to components provided by blocks.

This strikes me as a typical anti-pattern. What are we testing here? The CocoonBean or the components that it relies upon? If it's the latter, fine, but it's not a unit test anymore, it's an integration test and does not belong under the "junit-tests" target. If it's the former, it should be testable in isolation.

In any case, it would be probably advisable to load the CocoonBean under test with a cocoon.xconf derived from a "no-blocks-included" configuration.

        WDYT?

                Ugo




Reply via email to