15 Most Recent [RSS]
More...
|
Just Ten minutes without a test
A guy calling himself "Uncle Bob" posted an interesting story about what happens when you don't do Unit Testing for ten minutes.
I admit I'm not doing unit tests myself yet, but for my new hobby project with the programming language, I thought I might as well try out Xcode 2.1's new built-in unit testing support. If I find out anything interesting, I'll let you know.
The problem I had with Unit Testing so far was that I just didn't understand how the code I wrote for my unit tests would be less buggy than the code it's testing. But with this example, which mirrored things that happened to me several times, I finally realized: Unit Testing essentially is about hedging your bets. When you have code that works correctly, you can change its insides, and the tests will tell you the moment you break something that used to work.
Whenever I write new code, I usually write a small test app for it. The problem is that I usually don't look at that application anymore once I've verified it works. If I just took that code and threw it in a unit test with a few ASSERT()s, I could be sure I found out the moment I broke anything. If someone reports a bug, I can write a test case that shows me I've solved the problem, and if I ever do something that could cause the same bug again, I'll immediately know.
Add to that the "unlimited undo" that having my code in a Subversion repository gives me, and my apps are bound to become more stable. Now I'd just like to know why I didn't understand that last year when James Duncan Davidson gave a talk on UnitKit. | |