On 9 Apr 2007, at 13:08 , Hermann Himmelbauer wrote:
This is a small enough task that would make an excellent first
contribution to Zope 3... any takers? :)
Certainly interesting, but I'm still very new to Zope 3, so I'm
unsure if I am
qualified for this task.
Everybody has to start at some point :).
What if I check in code that accidentally breaks something?
The chances of that happening are low if you follow the guidelines:
always write tests for modifications and always run *all* tests
before checking in. We have automated tests for exactly this reason:
avoiding accidental breakage.
Also, the "checkin police" will be there to let you know when you
screw up :).
* Write a test that exercises the desired behaviour, best by
the zope.formlib/form.txt doctest. (We require automated tests
modifications, especially for bugfixes and new features).
This once again raises the question for me how I execute such tests
form.txt) - is there some magical Zope 3 command? Executing these
via "debugzope" does not always work, probably something has to be
Yes, most test require setup which we typically don't put in the text
file because it would be confusing. I suggest you read up on
unittests and doctests in particular (form.txt is a doctest). My book
(http://worldcookery.com) devotes a whole chapter to automated testing.
Note that re-playing doctests in the debugzope prompt is not an
actual *automated* test. The idea of automated tests is that
thousands of them can be run automatically with one command. Only
that way we can ensure that modifications in one place won't break
other code somewhere else: we always run that other code's tests!
When having Zope 3 installed from a tarball, you can run its tests
using a command like this:
[EMAIL PROTECTED]:~$ /usr/local/Zope-3.3.1/bin/zopetest -p
Running unit tests:
When in a Zope 3 checkout, you simply execute "python test.py -
p" (the -p flag switches on the percent display).
Zope3-users mailing list