[Zope-Coders] CVS and unit testing discipline

[Chris Withers]

Tres Seaver wrote:
> 
>   - We aren't doing a good job of "walking our talk";  in particular,
>     the tacit agreement to leave broken code or tests in place makes
>     it very difficult for anyone else to know how to contribute. 

Yup. That's what I found with 2.4.0 when I tried to run all the tests to check
Zope was working as it should be...

>     Tests
>     which can't be made to run should be commented out, with notes
>     explaining the difficulty, and probably a follow-up note to this
>     list explaining why.

Good idea

>     supposed to fix it, not make it go away by cheating.  Running the
>     *whole* suite before a checkin is a reasonable requiremenet:
> 
>       $ cd /usr/local/zope/Zope-head
>       $ cvs -q up -dP
>       $ python2.1 utilities/testrunner.py -q -a

Was there ever consensus that testrunner is the way to go? If not, is there any
work in progress to get consensus on a standard framework for running Zope
tests?

>     ugliness (what the XP folks call "code smells".)  Such ickiness
>     should probably also result in a note to this list, so that the
>     folks who know about the sources of ickiness can think about ways
>     to un-ick them.

Well, I un-icked ZCatalog by writing a replacement. Sadly, I need to get it to
scale; it currently suffers from the same problems as ZCatalog with TextIndexes.
I was hoping to make it 'pretty' before releasing it, but if anyone want to help
me get it to scale, I'd be happy to send the 'unofficial' code. I even got a
scalability testing framework for it ;-)

>     In fact, *anything* which can cause test breakage, or delay other
>     development, should be occurring on branches, and not on the trunk.

Definite big +1 from me :-)

cheers,

Chris