Showing posts with label Test Driven Development. Show all posts
Showing posts with label Test Driven Development. Show all posts

Tuesday, August 10, 2010

Test Driven Development and IPhone

Yes, we can:
http://developer.apple.com/tools/unittest.html

Here's a common development scenario: You've just finished building your application. You're confident that it works. You've put it through the paces, exercising every feature and checking every output. You're proud to say that it's stable, at least for the moment. But when you think about the next feature you need to add, you can't deny that low-priority thread of fear running in the back of your mind: “If I change the code, what might break?” You could certainly try to manually test out all the features of your application after each change, but after the second time doing this you're sure to become bored and make a mistake. Ironically, you feel like you don't have time to test.

If that scenario is familiar to you, here's the good news: Your computer has the cycles to keep that low-priority fear thread in check. If you supplement your visual inspection with automated tests, the computer will happily check the results for you, as often as you like. It's understood that it isn't always easy to write an automated test, but the effort you spend is a one-time investment that just keeps paying you back every time the test is run. And if that's not enough, writing the test might reveal opportunities for a better design.

And incidentally one of the best explanations of why writing unit tests actually saves time.

Tuesday, July 6, 2010

Festering code bases and budding code bases

A truly excellent read:
http://michaelfeathers.typepad.com/michael_feathers_blog/2010/06/festering-code-bases-and-budding-code-bases.html

Especially the concept that at the time of change, just adding code to an existing method, and not refactoring to a better structure, is perceived as more cost effective, but it’s just accumulate technical debts, that over time cost money in the form of interests. Same concept can be applied to write unit tested code: it seems to cost more at the time of change, but costs less in the long term, by flattening the curve of cost-of-change.