Demystifying Extreme Programming: Test-driven programming
By: Roy Miller
Keep it simple by writing tests before you write code
Summary: Test-driven programming is one aspect of XP that baffles programmers. Many of us make incorrect assumptions about what it means and how to do it. This month, XP coach and Java developer Roy Miller talks about what test-driven programming is about, why it can revolutionize your productivity and quality as a programmer, and the mechanics of writing tests.
For the last fifty years, testing has been viewed as something that gets done toward the end of a project. Sure, there may be integration testing while the project is going on, and testing doesn't usually start after all the coding is done, but it's usually in a later phase. However, proponents of XP suggest that this model is completely backwards. As a programmer, you should write tests before you write code, then write just enough code to get the tests to pass. Doing that will help you keep your system as simple as possible.
Writing tests first
XP talks about two kinds of tests: programmer tests and customer tests. Test-driven programming (also called test-first programming) most commonly refers to the first variety, at least when I use the term. Test-driven programming is letting programmer tests (or unit tests -- again, just a choice of terms) drive the code you write. That means you have to have the test before you write the code. The test drives the code you write by dictating what code you need to write. You write only the code necessary to make your test pass -- no more, no less. The XP rule is simple: If you don't have a programmer test, you don't know what code to write, so you don't write any code.
How to write tests first
All this theory is great, but how do you write a test first? First, I recommend you read Kent Beck's book Test-Driven Development: By Example (see Resources) for an extensive, book-long example. It talks not only about the mechanics of how to write tests and allow them to drive your code, but also why test-driven programming is such a good thing. I'll give a simple example here, to give you a taste of what I'm talking about.
Suppose I'm writing a system that has Person objects. I want each Person to tell me its age (as an integer) when I ask. Even though I haven't written a lick of code yet, it's time to write a test. "What?," you might say, "I don't even know what I'm testing. How can I write a test?" The short answer is that you do know what you're testing, you just don't know you know because you're not used to thinking that way. Here's what I mean.
You don't have any code yet, but you have an idea what the Person object should look like. It should have a method on it that returns the age as an integer. Because I work most often with the Java language, I use JUnit to write programmer tests. Listing 1 shows the JUnit test I would write for the Person object:
... to read more articles, visit http://sqa.fyicenter.com/art/