Thursday, September 30, 2010

Stumbling into unit testing

Well, I finally did it, I took a dip in unit testing last night. I've wanted to put it to use for some time, but have excused myself with the thought that it would take too long to figure out and what I really need to do is get on with writing real code. Riight... To my surprise and happiness, not only was it quick to get the unit testing ball rolling, but it was wonderfully satisfying to see those little tests succeed or even fail! It's one thing to write code that expresses some intent, and expect (more like hope) it will do what I want it to. It is quite another thing to write code, create a test [1], and see that test case prove that my original intent and the final result are one and the same.

I now have a feel for its utility that makes me excited to continue using it. To my new and naive understanding, a unit testing project is like a small console application that runs quickly and tells me simple but important things like "code A threw exception X", "test case B did not match the expected value Y", or "all tests passed and all seems well, sweet dreams". When compared to how I have done "testing" up to this point the time savings is enormous. That is because my traditional technique (for web application development for example) is write some code, compile code, launch web server and browser, login, browse to affected web page, and perform test case B. Had I only stopped making excuses sooner, the time and headaches I could have saved.

[1] Yeah I know everybody says write the tests than the code, red-green-refactor and so on, but I'm just starting. I look forward to growing in understanding, and learning when is best time to do what.

No comments: