Friday, July 25, 2008

Unit Testing: How Do YOU Do It?

[originally posted 6/2 on "Dev Blog"]

As developers, we all understand the importance of unit testing. We know that our code needs testing, and we know that before it goes to anyone else, we have to be that first line of defense against defects. At its simplest, unit testing is just taking a moment to try out your code. None of us is silly enough to think that we don’t need to try out what we’ve built.

But there are different schools of thought on unit testing, and different approaches to it. While simple unit testing isn’t very thorough, it’s easy to do and it’s a fundamental part of how we write code. Especially with web applications, it’s typical for a developer to write code, compile, and view the results in a browser – all with just a few keystrokes. Think back to the days when compilation could take hours (or even days), and you’ll realize that we’re fortunate to live in an era of quick compilation and quick results. And that’s just the point: we rely on those quick results to show us that our code is indeed working correctly.

A more thorough approach, however, is to use test-driven development, like that supported by the xUnit frameworks (NUnit, JUnit, etc.). This approach is an integral part of eXtreme Programming, adopted because it provides immediate quality feedback, which is important for any type of agile development. It turns out that it’s a very smart approach within any methodology (Agile, Waterfall, etc.). While test-driven development adds work to the development process, it pays off in a big way by decreasing the work in debugging. All reports indicate that the gains far outweigh the costs.

I’m not familiar with many other approaches, but I’m sure they are out there. What I would like to know is How do YOU do unit testing? As a new member to the team, I haven’t yet seen my teammates in action. So I thought I would ask. I’d like to hear not just from Max and Luis, who lead our development efforts, but also from the rest of the developers.

To be clear: I’m not asking how your apps get tested after they’ve been developed. I want to know how you test your apps during development. How do you know, on a day-to-day or moment-to-moment basis, that your code is doing what it’s supposed to do? I’m hoping you don’t just compile and pray. What process do you follow, probably between the time you compile and the time you check your code in, to make sure that it’s working properly?

Here’s my painfully honest answer: I have been getting along using the simple, less thorough method I mention above. It’s unit testing, but it’s not the kind I’d be proud of. I want to move to test-driven development, and use NUnit. It strikes me as a smarter and more efficient way to get things done. So I wrote this email to see if others on the team are using it, and if maybe they have some tips.

Anyway, let me know how you unit test. I’m curious to see where we all stand now, and where we’d like to take the team (if anywhere). Maybe I just need to catch up with the rest of you!

Ss.

No comments: