|P is for Practical|
After constantly reading about the joys of testing, I finally decided to buckle down and implement some tests for a piece of code I'm working on. After I got the first couple of tests written, I was hooked! I had to keep writing more tests. It was fun seeing exactly what contortions I had to do to test various bits of my application.
The pay off was immediate it. Soon after getting a basic test suite in place, I noticed that I had a spare file in my testing directory. I was pretty sure I didn't need it, but not totally. So I simple moved the file away and re-ran my test suite. Everything passed. Now I can delete the file and *know* I don't need it.
That's really what testing buys you. Not some vauge buzzword compliance or some random restriction, but security. Real peace of mind as you can make any change and *know* everything still works as it should.
For me, automated testing was really the obvious next step. I came to realize that I had been doing my own sort of informal testing. Everytime I made a change to my app, I would load it up and navigate through some of the screens, making sure it worked. But automated testing far surpasses this. With one press of a button I can instantly know that *everything* still works, not just the bits I remembered to test.
However while I was coding my tests, it occurred to me that what I was really doing was translating my project specification from a high level language (english) to a lower level one (perl) and in doing so creating something that could be actually used to check functionality. Which made me wonder, what about a way to check functionality without requiring this translation?
At first blush, it seemed rather simple. The majority of my tests were simple things, "ok($foo=~/bar/)" which you could easily translate to english (or keep in english, if you're thinking that way). Simply: $foo should contain bar. and you have an english statement that does the same thing as perl.
But thats not really much of a win, you're simply replacing a bit of perl syntax with the exact equivalent in english, and you still need the code to get the value in to the variable in the first place. You'd also need to repeat your self to test for all of the basic assumptions/restrictions you place on your product, such as what a method should return for no value and things of that nature.
At the moment I can think of no real way to translate between all of the high level assumptions we make when we're describing the project specification, sense so many of these are context sensitive in various ways, I would need a English->Perl translator, which would probably put programmers out of a job if such a thing could actually be written. Anyone else have any ideas on describing the project spec in a higher level / more natural language but still being able to be used as a test?