I'm programming a small application dealing with some trees, in which the value in a node is the plain sum of the values in the children. Following advices, mostly from here, I'm producing tests as I go (even if I've to admit that I first write the function, then the test, contrarily to the suggestion), but then I came into the present meditation.
Using Test::More, each single test looks checks something "atomic": is the return value true, is this equal or like to that, and so on. To check the results of the calculation, I basically test if the value in each node is what I'm expecting, thus traversing the tree and doing a test for each node.
As a consequence, the number of tests is likely to explode, and this is where I'm looking for some other meditations. I think there's nothing really bad in test bloating, because if any value is incorrect I'll be able to find exactly what and where, but I wonder how a final user would benefit from knowing this instead of a simple "this function doesn't work".
On the other side, I feel like I'm cheating doing all these repetitive tests, and having lots of "ok..." where I should really have one, that is the one related to the function I'm testing. I'm tempted to pack comparisons inside a function, and test only the outcome of this function for an "ok", but this would make troubleshooting harder for me, I fear.
For the moment, I'll stick to the bloating behaviour, because it'll be a limited distribution module, but I'm still curious: what granularity do you adopt in your test suites?
Flavio (perl -e "print(scalar(reverse('ti.xittelop@oivalf')))")
Don't fool yourself.In reply to Testing at the right granularity by polettix
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |