unittests with different parameters

[Roy Smith]

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.