cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira ...@upaya.co.uk>
Subject Re: [VOTE] Release on monday
Date Thu, 20 May 2004 09:00:47 GMT
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



Mime
View raw message