cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject Re: [GUMP] Build Failure - cocoon-block-fop
Date Tue, 08 Apr 2003 15:08:04 GMT


_______________________________________________________________________
         Stephan Michels               EMail: stephan@apache.org
         ICQ: 115535699                Tel: +49-030-314-21583
----+----|----+----|----+----|----+----|----+----|----+----|----+----|-|

On Tue, 8 Apr 2003, Nicola Ken Barozzi wrote:

>
>
> Stefano Mazzocchi wrote, On 08/04/2003 16.04:
> ...
> > So adding tests makes perfect sense, while adding documentation or dist
> > targets does not: if our documentation fails, the code dependency of
> > others projects will remain valid, so we should not impede others from
> > being able to build on us.
>
> Usually there can be three methods of doing this.
>
> 1 - One, which works with projects that are in alpha state, makes junit
> tests not fail, ie failonerror="false", so that a report can be
> generated and browsed. Same with distros.
>
> 2 - Another is to make a cocoon-test project, and have that depend on
> cocoon and unit test it. Thus the unit test can pass and cocoon give the
> jar. This is quite common for Gump, as you see from the project definitions.
>
> 3 - Finally there is super-strict mode, where a project doesn't want to
> give it's jar if not all tests pass. Not usually recomended.
>
> I'd go with 1 for unit tests, and eventually use regexps to nag on test
> failures if we need them later on.
>
> For functional tests like the anteater ones, case 2 is the best.

I'm for 3 ;-) That's reason why it called XP, and it forces you to
keep the testcases uptodate.

My 2 cents, Stephan.


Mime
View raw message