Working on my class project this summer, I decided to bite the bullet and do full unit testing. I've done unit testing before, but only in small amounts. In this case, I'm doing something akin to test driven development. I'm writing the tests very early and for everything. Not necessarily first, but in very close proximity to when I write the code. At first it felt painful. You can't code as fast. It sucks having to stop and write tests. Then I started making changes to the design. This is when it pays to have unit tests. It was great to make a change, press the "run tests" button, and look for the green bar to appear. If it didn't, I could easily go fix the issues and continue on. I didn't have to worry about breaking random things with my changes. Instead, if the tests passed, I could be confident that everything was still working. Unit tests are a little like a security blanket. Just having them makes you feel comfortable. In the end, I find myself more willing to make changes and to refactor the code.
One of my partners in this project has written some code that I will end up helping out with. He has no tests for his area. It's a lot scarier going in there to make changes. After doing some work, I will have no peace of mind that I haven't subtly changed things. This also points out another benefit of unit tests. It makes life a lot easier for the next person. It's not too hard to keep all of your own code in your head and know what effects changes are likely to have. It's very difficult to do the same with someone else's code. I want the ability to make what looks like an obvious change without having to read every piece of someone else's code first. Creating unit tests makes life a lot easier for whoever has to maintain the code later.
This brings up a use for unit tests that is mentioned in the literature but is not often considered in the real world. When you are asked to change "scary" code that doesn't have any unit tests, consider spending the first part of your schedule writing those tests. Not tests for the new code, but tests for the code as it originally exists. Once you have a comprehensive suite of tests, you can make changes with peace of mind.
Like, totally man.
ReplyDeleteBut, when you come to write unit-tests for that old scary code, guess what, its very hard. Big(-ish) monolithic functions that need breaking apart to test each bit (e.g. the bits that parse the data, separated from the bits that do the IO)... But you're scared to do so because you might break something in the process, and there's no tests to reassure you. Catch 22; or infinite recursion at least. :-(
Alan
That seems to come across in a much less supportive and respectful tone than I intended. Hmm, must treat blog comments like email, and give them many hours of consideration... :-)
ReplyDeleteAlan
TDD?
ReplyDeleteThe MSDN Ireland Blog on Team Edition for Database Professionals Walkthrough. Brian Harry on VSTS Web...
ReplyDeleteA recent analogy comparing software maintainability with a lobster triggered a moment of inspiration about the Gut Instinct Equation. From the Gut Instinct Equation we know that progress is not linear. What I am now pondering is if this is because o..
ReplyDeleteThe more things change, the more they stay the same. I can remember in the mid '70s learning that one of the design goals for a time-sharing interpreted envirionment was that the computer worked with you in test and development. But there has always been a part of the computor world that thought that test was for people who couldn't code.
ReplyDelete