Hedley Roos wrote:
> Chris mentioned unit tests. You do not have to write a new unit test.
> What is required is to have a look at the tests and then identify one
> that is relevant to your problematic method. This test should be very
> easy to read. The "hard" part is for you to expand this test to
> demonstrate the exception. This will typically require a few lines of
> code but since you already fixed a bug I assume it won't be hard to
> do.
Actually, I disagree with you here... big bloated tests that test huge
amounts in one go is not the way to go. I'd suggest that if it's a
specific problem, a new test should be added that does the absolute
minimum to demonstrate the bug...
> Then you have to run all the other tests to check that you haven't
> broken anything else by doing ./bin/instance test -s zope.something.
>
> Finally create a patch file and attach it to your original report on
> the tracker.
>
> Mmm, after writing all this I can see why it is a pain.
I can't. The testrunner is already there and buildout-based development
makes it trivial to run. svn already does the patch creation for you:
$ svn diff
> be able to get past that bit. Perhaps a kind Zope dev will pick up on
> this.
Unlikely with his attitude...
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
