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

Buy PEAA, too

[Amsterdam Vallon]

You can get Martin Fowler's "Patterns of Enterprise Application Architecture" in a bundle bargain at Amazon along with Kent Beck's "Test Driven Development" for $79.98 [link to PEAA bundle]

The Unix Philosophy

[cyber_rigger]

The Unix Philosophy

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

Book Draft is available online

[Googol]

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

Re:Tests are only as good as your requirements�.

[mikemulvaney]

I think you are missing the point. You seem to realize that you are never going to get rock solid requirements, which I think most people would agree with. But then you use that as an excuse to throw away XP?

Test Driven Development is a great way to deal with changing requirements. For a phone number validator, you would write up tests for all of the initial requirements:

testLocalNumber()

testLongDistanceNumber()

testTenDigitLocalNumber()

testAlphaNumericNumber()

Then when you deliver the application and find out that you need to deal with international numbers, you write:

testInternationalNumber()

You get a red bar, beacuse you can't handle i18n numbers yet. So get that working, and when you are on a green bar, then you know that it still works for all those US numbers and it works for the new foreign numbers.

Then you extend as you get new requirements:

testEnglishNumber()

testFrenchNumber()

testItalianNumber()

What is the alternative to this? You are still lacking requirements, even if you aren't doing TDD. But you wouldn't have any tests, and you wouldn't know exactly what your class can do for you.

Test Driven Development is not all about leaving test artifacts. The tests are constantly changing during development as your requirements change. The main idea behind TDD is to program from the client side of things first. This is similar to the idea of writing documentation first, with the added benefit that as you finish the tests, you prove that the class does what you want it to do.

-Mike

XP == Xtremely Pstupid

[copyconstructor]

One day my manager came and suggested we try XP. So I did what I normally do in such situations and did a search on the pattern [stupid management suggestion] +stupid and quickly turned up what I was looking for:

http://http://www.softwarereality.com/lifecycle/xp /case_against_xp.jsp

In two minutes I was able to save both myself and my company many man-years and headaches.

Re:XP == Xtremely Pstupid

[copyconstructor]

Oops, link should be:

http://www.softwarereality.com/lifecycle/xp/case_a gainst_xp.jsp

How XP of me.

scrum methodology plus xp == happy developers

[maharg]

I work for a largish (the largest?) media organisation in the world cutting code as part of a team of 4 developers plus a senior developer.

We've been using Scrum and Test Driven Development for about six months now, and there is NO WAY I'm ever going back to writing code without writing tests first.

Scrum (see http://www.controlchaos.com) is a "lightweight" development methodology. It's developer driven (no more gannt charts !!!!), and it's agile, meaning that it embraces change throughout the project lifecycle. I can highly recommend it. But I digress...

Test Driven Development is something that every halfway serious programmer should be doing IMHO. It doesn't replace the initial back-of-a-fag-packet design stage, nor does it stop you designing elegant and effective architectures. What it does do is:

• force you to define rules that your code must obey by requiring that you write tests first. This really is useful, because it makes you think about the implications of how your application behaves.
• facilitate unit testing - you know that every function, procedure etc works as expected, and fails as expected.
• facilitate regression testing - when you change / enhance / refactor or otherwise modify your codebase, you know that you have not broken any existing functionality, because you will re-run the test suite against the modified code. Of course, you will have added tests for the new / changed functionality before having coded the new / changed functionality.
• focus your mind on developing the required functionality - when all the tests pass, it's time to stop coding. No temptation to just tweak a line of code. Careful with that axe, eugene.

So I can recommend TDD. Check it out. By the way, we're coding mainly in python with some java thrown in too.