Roy Smith wrote: > Writing one test method per parameter combination, as you suggested, is > a reasonable approach, especially if the number of combinations is > reasonably small.
The number of parameters and thus combinations are unfortunately rather large. Also, sometimes that data is not static but rather computed from a loop instead. There are a few optimised computations, where I compute the expected result with the slow but simple version, in those cases I want to check a whole range of inputs using a loop. I'm wondering, classes aren't as static as I'm still used to from C++, so creating the test functions dynamically with a loop outside the class declaration should be another possibility... > 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? ;) Thanks Roy! Uli -- Domino Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 -- http://mail.python.org/mailman/listinfo/python-list
