unittests with different parameters
roy at panix.com
Mon Nov 22 15:47:44 CET 2010
In article <ddbqr7-5rj.ln1 at satorlaser.homedns.org>,
Ulrich Eckhardt <ulrich.eckhardt at dominolaser.com> wrote:
> > Yet another possibility is to leave it the way you originally wrote it
> > and not worry about the fact that the loop aborts on the first failure.
> > Let it fail, fix it, then re-run the test to find the next failure.
> > Perhaps not as efficient as finding them all at once, but you're going
> > to fix them one at a time anyway, so what does it matter?
> Imagine all tests that use INVERT_X fail, all others pass. What would your
> educated guess be where the code is wrong? ;)
Well, let me leave you with one last thought. There's really two kinds
of tests -- acceptance tests, and diagnostic tests.
I tend to write acceptance tests first. The idea is that if all the
tests pass, I know my code works. When some test fails, that's when I
start digging deeper and writing diagnostic tests, to help me figure out
what went wrong.
The worst test is a test which is never written because it's too hard to
write. If it's easy to write a bunch of tests which verify correct
operation but don't give a lot of clues about what went wrong, it might
be worth doing that first and seeing what happens. If some of the tests
fail, then invest the time to write more detailed tests which give you
more information about each failure.
More information about the Python-list