Re: A simple unit test framework
On May 7, 11:12 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
In other words, you have to write the code first, to know what
the branches are.
This overlooks another powerful feature of TDD - algorithm discovery.
You may not know how to solve the problem when you write the first test.
As each successive test adds functionality to the unit under test, the
algorithm will find its self. Only then do you know what the
*required* branches are.
But suppose you never add a test which triggers a required
branch? You'll admit that it isn't reasonable to test every
possible double value. So how do you choose the test values in
such a way as to ensure that they trigger all of the required
branches? And that they trigger them at the right place?
Take a simple example: a function that requires special handling
for very small values. Obviously, you'll end up testing some
very small values, find that the results are wrong, and modify
the code to handle them. But having done that, how does
"testing" help to determine the cut-off point? (Once you know
the cut-off point, of course, you will add the two bounding
values to the test suite. But you should use numeric analysis
to find the optimal cut-off point.)
And what about threading problems? Gianni has claimed that his
test find the error I found in g++'s std::string. Maybe...
I've not yet been able to evaluate it. But would it have
occured to anyone to write such a test unless the error case
were known in advance? There is an almost infinite number of
combinations of doing A in one thread, and B in another; I doubt
you can cover them all. And of course, the actual problem only
occurs very rarely once you've got the right operations.
Also: how do you know that the tests are correct. At first
glance, I think there was a problem in Gianni's test. I could
be wrong, because I'm not familiar with the surrounding
environment, but basically, how do you know that the test tests
what you want it to test, and not something else? How do you
know you've covered all of the special cases?
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34