|
|
|
|
|
|
by dripton
5036 days ago
|
|
|
Obviously your test case is insufficient. In Kent Beck's "Test Driven Development by Example", he starts just like this, with an insufficient failing test. Then he writes a minimal function that passes it. Then he adds another test, then improves the function until it passes both. By the time he's done, he's got tests for all the edge cases he could think of. I think it's a great way to make sure you cover all the edge cases, for a sufficiently complicated function. I don't have the patience to write all my code that way, though. |
|
|
Yes, it is. The point is that even given many additional test cases of the same type, they will remain insufficient, unless of course you’re planning to test the entire input domain, which I imagine is going to take you a while.
Clearly at some stage you have to replace satisfying isolated cases with some form of generalised understanding. At that stage, you’re no longer coding to the tests.
This is not to say that unit tests can’t be useful. On the contrary, I find them a valuable tool for many programming jobs.
However, as I have observed before, the plural of “unit test” is not “proof”. I do find it frustrating when I see overconfidence instilled in too many developers just because they have a suite of unit tests available. Using TDD can’t magically guarantee that a program actually satisfies all of its requirements. Refactoring without thinking isn’t magically safe as long as the code still passes the test suite. Writing code to the test is not a substitute for understanding the problem you’re trying to solve and how your solution works.