Test-Driven Development by Example

PinglePongle writes "Kent Beck is well known as one of the main drivers behind eXtreme Programming -- a style of development which favours a very disciplined but low-formality approach to coding. Writing applications 'test-first' is one of the practices of XP, and this book explores the subject of test-driven development in detail." Read on for the complete review. Test-Driven Development by Example author Kent Beck pages 220 publisher Addison Wesley rating Superb reviewer PinglePongle ISBN 0321146530 summary Kent Beck -- author of the original Extreme Programming book -- explains in detail how to turn your development world upside down by starting with the test, then writing the code.

What it's all about: Test-driven development is about being able to take tiny little steps forward, test that the step took you in the right direction, and repeat. The "TDD Mantra" is red/green/refactor:

• Red: write a test which will exercise a feature, but which will fail (because you haven't yet written the code)
• Green: make the test succeed, doing whatever you need to do to get to "green" as quickly as possible -- don't worry about prettiness
• Refactor: now that you have code which passes the test, eliminate all the duplication

The book then shows 2 fairly detailed examples of a development project (or snippet of a project) which progress using this style of coding. The first example deals with the creation of multi-currency capabilities for an existing project. In the space of 17 chapters, the author walks you through the creation of 6 classes (1 test class, 5 functional classes), complete with the thought-processes behind them. The code is written in java, and is trivially easy to follow, because it gets introduced in tiny little chunks; most chapters are less than 6 pages in length.

The second example is the creation of a unit testing framework in Python. It is significantly more complex and real-world than the first example, but again proceeds in very small steps, and in small chapters.

The final part of the book contains patterns for test-driven development -- practical real-world advice on how to do this stuff for real. Nearly all the "patterns" are phrased as question/answer pairs, and they range from deeply technical design patterns to advice on the best way to arrange the furniture.

What's good about the book? Kent Beck is a very good writer -- his writing is clear, he is not afraid to leave out stuff he assumes you can guess for yourself, but when he does go into detail you feel it is necessary to get the big picture, rather than mere geek bravado. Even if you don't adopt Test-Driven Development, many of the ideas are well worth considering for your day-to-day coding situations.

What could have been better? The book stresses the importance of taking 'little steps,' and sometimes you feel impatient to move to more challenging tests before properly finishing the current chapter. I was also hoping for more of a discussion on the practicalities of unit testing database-driven systems, where you frequently have to test business entities which are closely coupled to the database.

Summary If you code for a living, or manage people who do, you should read this book -- it's a quick enough read -- and consider some of the assertions it makes. If you feel you're introducing more bugs than you expected, if you feel uneasy about how close your work matches the requirements, this book gives you some powerful ideas. You can purchase Test-Driven Development by Example from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

I always test drive my apps

[Amsterdam Vallon]

Although it sucks to lose 20% of your code when you drive it off the lot.

What the XP folks have right (and wrong)

[thac0]

The reason some XP projects are successful is because they actually have testing as part of the game plan. It is *shocking* to me, having been in the industry for better than a decade and pounding code for 20 years, the state of testing in corporate america. Just atrocious.

There are many labs that don't test at all, and a vast majority test poorly. I've worked in some fortune 500 labs that didn't test at all. Scary stuff. Nothing life threatening, but all of a sudden I wasn't so convinced that the reason my account was misconfigured was because *I* gave wrong data. Simply bug riddled. Those that do test often do so manually. Forgetting for a moment that humans are likely to take short-cuts and not bother to execute tests they perceive to be out of the scope of their recent change, they are failable. Of course they are, that's how the bugs got there in the first place.

So, the XP folks have the testing thing down. They test before the code is written, and their tests are automated.

Then they take leave of their senses. The claim that because they've successfully turned one idea on it's head (i.e. testing *first*) that they can turn others is ludicrous. Design first is still valuable guys. I've eliminated thousands of bugs simply by having the right design to begin with. Waiting until you've cobbled something together that passes the test and then hoping that your boss will allow you to refactor is a loser. If it weren't Scott Adams wouldn't be a millionare.

So, write your tests first. But do your design before you code, not after you've put together a thousand lines of crap.

Re:What the XP folks have right (and wrong)

[Lumpish Scholar]

... some XP projects are successful is because they actually have testing as part of the game plan.... the XP folks have the testing thing down.

The best thing about XP is that, with the possible exception of test-first (a.k.a. test driven) development, none of the practices are new and original. I mean that in the best possible way! All the practices are tried and true, based on experience long before Kent Beck was using the word "extreme" this way.

Then they take leave of their senses.... Design first is still valuable ...

"Design" in the pure waterfall sense -- do 100% of the requirements before doing any of the design, do 100% of the design before doing any of the coding -- doesn't scale up to large projects or rapid development. It's important to use an iterative approach: do a little analysis, do a little design, do a little coding, do a little testing, repeat until done.

XP breaks the design/coding/testing cycle into very small iterations, each one as big as one automated unit test case. It's a very exploratory style of software development. XP doesn't mandate any high-level design artifacts (though it doesn't forbid them either).

What none of the XP books say is that developing unit tests is a design activity, and the unit tests are design artifacts! Unit tests outline the responsibilites of classes, in the original responsibily-based style of object oriented design.

XP programmers do design on whiteboards, and in their heads. Some of these artifacts are lost. Some would have become obsolete in a hurry. (The unit tests are guaranteed not be obsolete, at least as long as they're passing.)

I'll take that, any day, over a hundred pages of out-of-date UML diagrams.

Haven't we...

[Some Bitch]

...been doing this for years anyway? My code development cycle has always been... 1. Write code to use function/procedure. 2. Write function/procedure. 3. If function/procedure==fucked return to 2 and unfuck. 4. Once it works, tidy it up. Now it appears someone else has added steps 5 and 6... 5. Write a book about it. 6. Profit!!!

Dibert and eXtreme Programing

[QEDog]

What would Dilbert do?

Here and here!

I love buzzwords with X anyway...

Is XP good?

[timeOday]

Now that XP has been "out there" for a while, does anybody have some war stories?

Does the reliance on incremental development and refactoring rather than a intricate, up-front design really work, or result in a big wad of band-aids?

Is pair programming OK, or do you sometimes get stuck with the nitpicker from hell who has to have every detail his own way?

Is close involvement with the customer good, or does it just give them daily opportunities for endless bright ideas that prevent convergence?

Just wondering...

Re:Is XP good?

[silkySlim]

I can't speak for XP specifically, but lightweight development has been nothing but a positive experience for my team. But it's a tricky question. Because if you truly believe in the "Agile" methodologies, you find that the development process quickly becomes customized based on your team members and type of project. It's all about creating the path of least resistance for your team while still moving towards the end product.

I work in a game studio where our last project had 6 months of pre-production time. We generated reams of technical design documents. The intention was good, but they were never maintained or even referenced after their initial creation. We just said "documentation is necessary" and it needed to be done. In production, the team wasn't on the same page. Every programmer had a task list they just milled through. The assumption was the initial requirements won't change. The result was ugly. The product was subpar and a couple months late. Everyone was miserable. It sucked.

I'm currently leading a new project here. We're 6 months into production and every milestone has been delivered ON TIME and accepted by our customer. The team is focussed on the current milestone, there isn't a lot of process to get in the way. The best part is, writing code is fun again. We don't have goals we can't accomplish. And we fully expect the product requirements to change during production.

I could get into specifics about our process. But I don't think it would be that helpful. I think specific methodologies like XP are guidelines to get you started. From there, you really should re-evaluate your process frequently (a fundamental excercise to be "Agile") and make changes as necessary. Kind of like optimizing your code.

The following links gave me all the information I needed to devise an initial process plan (which included TDD). But once it was put into practice, it naturally evolved into the process we have now (which doesn't include TDD)...

The New Methodology by Martin Fowler

The Agile Manifesto

Agile Software Development Ecosystems by Jim Highsmith

I also suggest reading the chapters on "thematic milestones" in Writing Solid Code.

Re:Is XP good?

[dubl-u]

Hi! I've been doing XP on and off (depending on client preferences) for a couple of years.

I'm immensely happy with it. It's not a magic bullet, but gives me the tools to solve a lot of common problems.

Does the reliance on incremental development and refactoring rather than a intricate, up-front design really work, or result in a big wad of band-aids?

Yes, it works. It takes a bit to learn how to do it well, but it works.

Indeed, in some ways, it works better. When I did most of my designing up front, I had to guess about a lot of things. Now I'm a pretty good guesser, but I'm not perfect. And since I knew I was making designs that I had to live with for years, I tended to play it safe, putting in things that I would probably need someday. I hoped.

Now, I don't put anything in until I know I need it. This keeps the design cleaner, and saves me all of the time I would have spent on bad guesses and things obsoleted by changing requirements.

Is pair programming OK, or do you sometimes get stuck with the nitpicker from hell who has to have every detail his own way?

I like pair programming a lot, and more people are good at it than you would expect. But some people are indeed pains in the ass; just last week we had to sit one guy down and have The Talk with him. If he doesn't shape up, he can go be a nitpicking cowboy on somebody else's project.

Right now I'm also doing some solo work, and it really suffers from the lack of a pair.

Is close involvement with the customer good, or does it just give them daily opportunities for endless bright ideas that prevent convergence?

It can work really, really well. The trick is that you must let them steer the project, so that they can see that asking for all sorts of random stuff means that their precious project will be screwed.

For example, I and another fellow were recently called in to work on a project that was six weeks from delivery and running late. The product manager handed us a one-page spec, spent 30 minutes showing us the existing code and said, "So can you do that in time?"

Now the only honest answer was, "I dunno, but probably not with all that you've asked for." But we walked him through the XP practice known as the Planning Game, where we broke his requirements down into bite-size chunks, wrote them on index cards, and then he ordered them by importance. There was far more work than could be done in time.

So then we asked him to draw a line at the point which, if we didn't reach it, he would slip the date, and if we did, he would ship. It cause him great pain, but he did it. Then we agreed that we would start developing and see how things were progressing.

As time went on, he, like any client, had all sorts of great ideas, and so did we. Every one got written on a card, and we asked him to place them wherever he wanted in the stack. This forced him to make tradeoffs; the more stuff he put in before the release, the farther away the release would be.

When the six weeks were up, we shipped a product with less than half of what he originally asked for. But instead of being pissed, he was happy! He got the half that was most important to him, and he was the one who made every choice about scope, so it wasn't our fault, that was just how things were.

And best of all, because we'd stuck to the XP practices and done extensive testing, there have been no bugs reported against our code. With code that solid, we're glad to start extending it, instead of the usual pattern where a big deadline push means the code is crap.

So yes, I like XP a lot. I get to write good code, polish the design, and have good relationships with the business folk. It rocks!

Moving beyond XP: XXP

[Waffle Iron]

XP testing techniques are great in theory, but there is still a gaping hole: if your tests aren't correct, your program could still end up flawed.

That's why I've moved on to XXP, which focuses first on correctness of tests. First, I write a test that tests a test. Then I write the test. I test the test until the test tests ok. Then I write a test for another test, and so on.

My pair programming partner is currently working on an idea he calls "XXXP". I'll post our results if we ever finish a project without getting lost in infinite recursion.

Is there anything here for the GUI developer?

[kahei]

I'd be the first to admit that XP offers a lot of risk-reduction -- for teams that are working on things that are easy to unit-test.

With a class that is supposed to take in a bond and output the yield curve, it's easy to write a unit test. But what about the next class, that renders the yield curve on the screen? What about the complex, distributed system of Excel objects and forms things that draw a network and things that flash green and go 'ping' to indicate a change, that are equally necessary but generally much harder to write and much more likely to go wrong?

Has anyone tried to apply test-first programming to complex guis? I can't say that any obvious way to do it has ever occurred to me. Worse yet, when I ask I generally find that people either

a) Are in the same position as me, or
b) Believe that a GUI is a little thing you spend a couple of days on after you finish the application

So, for now XP is something I read about rather than something I actually do.

Success Stories?

[Lucas Membrane]

A few years ago, the XP promoters were bragging about the Chrysler Compensation System, the first big XP project. They were redoing all of Chrysler's payroll systems, they were part done, they were succeeding where much larger efforts had failed, and the new managers from Mercedes wanted them to finish it so that they could go on and apply XP to other problems.

Last I heard, the Chrysler Compensation System was not finished, scrapped prior to going into production. What are the more recent projects that demonstrate how well XP works?

Re:Success Stories?

[Joseph Vigneau]

Any ideas why it failed?

Hear it from the players players themselves.

One of the benefits of XP is that it can tell you much earlier about whether or not to terminate a project in the first place. From Extreme Programming Explained:

One of the features of XP is that customers can see exactly what they are getting as they go along.

-- Kent Beck

Do we need a book for every rule of XP?

[Anonymous Coward]

What? Is he going to write a book for every rule of XP?

Testing is important, but XP testing philosophy is a catch all for actually thinking about your product and the purpose of you product. XP is about making hack programmers look legit. XP has some good points, such as an emphasis on simplicity, testing, and customer satisfaction, but mostly it's about making bad habits look good, like no design and iterative feature hacking with ignorance to the bigger picture of the app.

Some design up front is important. Documentation is important. Code ownership is important to an extent. In a medium to large system, having everyone able to change any line of code is just stupid. People change shit and don't have a clue why the code looks the way it does. One of the arguments for no code ownership is that a lead architect can't keep it all in his head. Well, what about a team of that consist of many folks that aren't as capable as that lead architect? they are able to comprehend the whole system according to XP. And, they are allowed to change whatever they want, when they want. So, get a couple of average programmers with large egos, and you have a lot of problems.

XP is great for people who are happy doing bug fixes all day instead of avoiding the bugs to begin with. The assertion that XP results in less bugs is pure speculation and from my experience, a very misleading claim. Just because your test succeeds doesn't mean that your program is correct. And if the test is the only glue validating the success of your final solution, you're screwed.

Re:sounds great but...

[Lumpish Scholar]

I just can't stand other people nozing around in my half completed code ...

Then you ought to (1) try the other XP practices before you try pair programming, and (2) learn how pair programming really works!

... the extreme attention to testing ...

You don't think testing is important???

... and the team-spirit you ought to have ...

Check out the work of James O. Coplien. He's an extremely hard core C++ guy, but when he was doing research at Bell Labs, he descovered that organization effectiveness was far more important for software development productivity than any technological advance.

I once worked at a start-up where someone started on Monday, and never came back after Wednesday night, leaving a voice mail message that said, "You never told me I was going to have to work with other people!"

You're going to have to work with other people. The better you work with them, the better you work, the better everyone works. (Hugs not required.)

Tests are only as good as your requirements�.

[(H)elix1]

Requirements are the Achilles heel of XP. Without rock solid requirements, you are just guessing for the test scripts.

Take a trivial example -- an entry form for a phone number. What is a valid phone number? Add in real world things like extensions, folks using alphanumeric substitution (1-800-DISCOVER), and internationalization and it gets interesting. Now a test driver is not that big of a deal if you know what to put in it. From a design standpoint, it would really be nice to have solid requirements and test scripts that provide concrete examples as to what the business was asking for. Real world? I could only dream for mediocre requirements that might resemble not only what they asked for, but what they want.... At least enough to try and read their minds.

Book Draft is available online

[Googol]

here, [pdf,yahoo.com] with more information here[vt.edu].

My (mixed) experience with test-driven development

[Lumpish Scholar]

I've done a little test-driven development on my own.

Test-driven development seems to call for a series of baby steps, each corresponding to a unit test case. Unfortunately, I wasn't always able to identify "the next baby step"; even if I could pick what I thought was the next unit test, I sometimes found myself spending far too much time, and writing far too much code, for just that next test.

I also sometimes found that "the next test case" already passed. I don't know if I wrote more than I needed to early on, or I picked the wrong next case, or if there's more to all this than I've picked up.

When I was in good TDD mode, I was flying; test, red, code, green, refactor, green, next! It's a very rapid, and very intense, experience. There's a reason XP usually calls for a 40 hour week; by the time you're done with a few hours of this, you are tired! (But you've gotten a lot done.)

Re:sounds great but...

[October_30th]

You're going to have to work with other people. The better you work with them, the better you work, the better everyone works. (Hugs not required.)

I couldn't agree more.

I can't think of many jobs - at least for college/university educated people - that do not require soft skills like ability to work with your coworkers and communication (meetings, presentations, acting as a tour guide for VIPs, etc.).

I used to hate having to deal with other people any any way. In fact, that was one of the reasons why I decided to embark on a research scientists (Physics) career. As a scientist I wouldn't have to deal with people, give talks, socialize or - most imporant of all - end up in any kind of a manager/boss line of work. I would just sit, think and write papers. That's what I thought and boy how wrong I was.

Most science, and experimental physics in particular, is done in groups. There's no way around it. You can't run a lab alone so you need to have people around you. Even as a postdoc you have to be able to hire good PhD candidates and supervise them. You have to be able to interview them, understand what makes each of them tick at workplace and how to manage them to get the best out of them.

Then, unless your lab is established and extremely well funded, staffed and equipped, you often need collaboration from other groups. Making contacts with other scientists and establishing mutually beneficial collaboration requires publicity (talks!), diplomacy (socializing!) and patience.

A person who cannot work with other people simply does not fit into this environment. No matter how brilliant scientist he is, without the social skills he is very likely to turn out as nothing.

I still get slightly nervous when I have to a give a talk. I still don't like meetings. However, I have grown fond of managing people, because, as difficult as it sometimes can be, it's a wonderful feeling to see your highly motivated and skilled people working with you in harmony. The older I get the more I appreciate social skills over raw intelligence or mathematical/logical ability. If it all comes in one package, jolly good. However, if I had to choose between a budding physics genius with a highly abrasive personality and a slightly well performing person with good social skills, I'd choose the latter. No question about it.