Re: Refactoring makes unit tests obsolete

[DrHyde]

Try not to think of the tests as testing the code. Think of them as testing your documentation. Good documentation will describe all the different types of input to your program (or to each function your library exposes, or whatever) - those types might be FOO, BAR, BAZ and a catch-all "anything else" - and all the possible types of output. Possible outputs include things like a calculated value, a list of values, "dunno", "i've died because your data was stupid" and so on.

As an example, imagine a function is_even(). You might document it as "this function takes a positive integer, and returns 1 if it is even, 0 if it is odd. In all other circumstances it die()s with the message "your father lies down with sheep".

Write your tests to make sure that all of what you've documented actually happens. So there's several things to test here:

• does it die when given values 0, -1, 1.3, "weasel", "4 bees" or a reference?
• does it die when you pass it a list (remember, it takes *a* positive integer)?
• does it return 1 for each of 2, 1000000, and 2**189?
• does it return 0 for each of 1, 999, and 2**3000 - 1?
• does it emit a warning for any of the above tests?

Yes, my choice of some of those data come from experience of how stuff fails in perl and other languages :-)

In your example of rewriting stuff because you understand the problem better, presumably this means that you will have updated the docs to better describe what it does. So you update your tests *because the documentation has changed*.

OK, that was a bit of a simplification! Obviously real-world tests are influenced by the code you're testing. When you write the code you *know* what its corner-cases are. You can see where (eg) the off-by-one errors might be and what would trigger them. So you would write extra tests for those cases.