Ugo Cei wrote:
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.
This is all fair comment. Whilst I have a 'unit test' for the bean, in fact, the bean really depends upon the entirety of Cocoon, and is thus really more of a functional test. Given that some blocks have been known to break the bean, it is important that the test is run across the entire Cocoon.
It is there somewhat more akin to an anteater test. Therefore, given these facts, I propose to leave the CocoonBeanTestCase disabled, and simply remove the test suite (as it isn't needed anyway.). I will continue to use the test case locally on my own testing, and will reflect on a better place for it (or some equivalent) within the build process, perhaps alongside the anteater tests.
Upayavira
