forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Testing (Re: code vs. talk)
Date Thu, 18 Nov 2004 14:30:27 GMT
Evrim ULU wrote:
> Hash: SHA1
> David Crossley wrote:
> | Dave Brondsema wrote:
> | There is a trade-off.
> |
> | This "patch-then-review" process needs to be qualified.
> | Developers need to be sure to provide a clear log message
> | to accompany the patch, so that we all know the purpose
> | and the consequences. Also add documentation where
> | possible. Then, if it is really necessary, we can
> | discuss later.
> I hate patch-review method. Current Linux-Netfilter project does this
> and somebody sends/apllies huge/core patches and attach a post-it like
> note like the following: "Lets see what will break?"

Well We are not advocating massive patches without discussion. Minor, 
evolutionary changes are patch-then-review, major changes are discussed 
and planned first.

> IMO, only solution is unit testing. After a patch is applied all unit
> tests are run to see what is broken.

I agree with the testing comment, but I would rather see testing 
*before* commit.

> I have absolutely no experience
> with cocoon unit testing so any ideas are welcome. I'm sure some members
> have experience related to this topic.

Well unit testing (as in JUnit) is not totally relevant here since most 
of what we do is XMAPs, XSL etc. More appropriate is that we test we can 
output everthing we are supposed to and that it looks the way it should.

We do have some testing in place (do "build test", but it does need to 
be enhanced - and I, for one, have to get into the habit of using it). 
This needs extending.

There are two popular test frameworks for this kind of testing (that I 
am familiar with):

Anteater -

Canoo Webtest -

> Apache has gump system for
> unit-tests of sub-projects AFAIK. 
> Maybe we should try to use it since
> forrest is built on top of maven (+1).

We are part of the GUMP setup.

We are not "built on top of Maven", not sure what gives you that impression.

> As a conclusion, i will support any method that can be measured.
> Otherwise it'll be subjective and will change from person/developer to
> person/developer and i simply don't want forrest community efforts to
> degrade in time.

I can see this becoming an argument - I've seen it loads of times before 
on Open Source lists. I will refrain from giving my view (as it is not 
identical to your own), but would encourage you to help out with the 
aspects most people agree on - testing.


View raw message