|Perl: the Markov chain saw|
When test-driven development just won't doby Ovid (Cardinal)
|on Aug 04, 2005 at 01:58 UTC||Need Help??|
Today at a testing talk at OSCON, dominus raised an important point. How do you write a test when you don't know what you're going to be testing? This is actually more common than you would think. I've discovered this happening in two different cases. The first case is when I've got a neat idea but I don't know how to implement it. When that occurs, I often just play around with code and see what happens. Sometimes I'm playing around with the code for a long time, running it by hand, seeing what it does, etc.
The second case, though less common, is when I'm porting code from another language. Usually that code lacks tests. Further, sometimes I'm either unfamiliar with the language or, more commonly, the code is very dense (or I am) and I'm not sure what it's doing. However, by porting all of the code I can compare end results and see that they're the same.
So how do I do test-driven development here? wickline mentioned that he'll then comment out the code and then start writing tests, adding back in code as he has the tests. I'd like to expand on that for a bit.
When I comment out the code and write the tests, there are three cases that can occur for each test.
The first case is the desireable one. Theoretically, I can then add back in the code I've written and cases 2 or 3 subsequently apply.
However, the code will sometimes fail in an unexpected way. If I'm writing a test that a particular line read from a file matches a regex and the test tells me that I'm trying to read from an unopened filehandle, it means I have a poor understanding of my code and I need to find out what's going on.
Sometimes, though, the test will pass. Once I had a test pass and it was because I had forgotten about some previous input validation I had. As a result, this suggested that I was on the verge of writing code I didn't need.
A common case where tests pass is with the can_ok $CLASS, $method; test. This gets tricky. Did I already write a method with that name? Did some naughty module import that method into my namespace? Did I inherit the method and am about to override it? Once again, I find myself in the position of having a poor understanding of my already written code and backing out the code and then writing a test protects me once again.