Product Description

This book teaches programmers how to make Test Driven Development (TDD) work in their organization. TDD is unique because it forces the programmer to write tests for code before the code is actually written. This process is the reverse of how software testing has traditionally been conducted, but TDD ensures that software is produced more efficiently. A test-first mentality allows the programmer to define, specify, illustrate, limit, and drive the code, resulting in documented, tested, code that is as simple and lean as possible. The book also presents tools and techniques, and all major points are supported by numerous examples (including an entire project, end-to-end) and exercises.

Product Details

• Amazon Sales Rank: #443035 in Books
• Published on: 2003-07-12
• Original language: English
• Number of items: 1
• Binding: Paperback
• 592 pages

From the Back Cover

Test-Driven Development: A Practical Guide

David R. Astels

Foreword by Ron Jeffries

• The relentlessly practical TDD guide: real problems, real solutions, real code
• Includes a start-to-finish project written in Java and using JUnit
• Introduces TDD frameworks for C++, C#/.NET, Python, VB6, and more
• For every developer and project manager interested test-driven development

Make Test-Driven Development work for you!

Test-Driven Development: A Practical Guide enables developers to write software that's simpler, leaner, more reliable... just plain better.

Now, there's a TDD guide focused on real projects, real developers, real implementation challenges, and real code.

Renowned agile development expert Dave Astels shows TDD at work in a start-to-finish project written in Java and using the JUnit testing framework. You'll learn how "test first" works, why it works, what obstacles you'll encounter, and how to transform TDD's promise into reality.

• o Relentlessly practical! Full of downloadable code examples, hands-on exercises, and a fully hyperlinked version of the "resources" appendix
• o Introduces powerful TDD tools and techniques--including key JUnit extensions, presented by their creators (Scott Ambler, Tim Bacon, Mike Bowler, Mike Clark, Bryan Dollery, James Newkirk, Bob Payne, Kay Pentacost, and Jens Uwe Pipka)
• o Covers refactoring, "programming by intention," mock objects, and much more
• o Discusses TDD frameworks for C++, C#/.NET, Python, VB6, Ruby, and Smalltalk
• o Introduces previously unpublished test-first techniques for GUI software
• o Contains appendices introducing eXtreme Programming and Agile Modeling
• o For all programmers and project managers

Read this book if you're ready to write code that's clearer, more robust, and easier to extend & maintain--in short, if you're ready to write better code!

About the Author

Dave Astels has close to twenty years' experience as a software developer in areas ranging from embedded environment control to intellectual property protection systems to electrical energy trading systems. For more than a decade, he has been working exclusively with object technology. He runs his own consulting company specializing in Extreme Programming and pervasive Java solutions. He is the co-author of A Practical Guide to extreme Programming (ISBN 0130674826).

Excerpt. © Reprinted by permission. All rights reserved.

PREFACE

This isn't a book about testing.

This is a book about a way of programming that leads to simple, clear, robustcode. Code that is easy to design, write, read, understand, extend, and maintain.

This is a book about thinking, designing, communicating, and programming.It's just a really nice side effect that we end up with a comprehensive1 suite oftests.

This book explores Test-Driven Development, Test-First Programming, callit what you will: programming by writing the tests first, then writing the codeneeded to make the tests pass. Specifically, working in the smallest steps possible:write just enough of a test to fail, write just enough code to make it pass, refactorto clean up the mess you made getting the test to pass.

This book focuses on the Java programming language and uses Java examplesthroughout. It is assumed that the reader has at least an intermediateunderstanding of Java (and a working Java system if you want to try out theexamples for yourself).

Even though the focus is on Java, Part IV looks at other prominent membersof the xUnit family for several popular languages. This is done by taking the firsttask from Chapter 10 and recasting it in the various languages. This provides agood comparison of the different frameworks.

EXTREME PROGRAMMING

Test-Driven Development is a core part of the agile process formalized by KentBeck called eXtreme Programming (XP). XP is probably the most agile of the agileprocesses, being extremely low overhead, and extremely low ceremony. However,it is extremely high discipline, very effective, and incredibly resilient tochange.

That being said, you do not need to adopt XP in order to practice TDD andgain the benefit from it. TDD is worth doing on its own. The quality of yourcode will improve. Of course, if you are doing XP it's well worth it to get reallygood at TDD.

TDD is one of the main design tools that we have in XP.2 As I mentionedearlier, the fact that we end up with a set of tests is a very pleasant by-product.

Because we have those tests, we can have confidence we haven't inadvertentlybroken anything if the tests ran successfully before the change and after it.

Conversely,if a test fails after we make a change we know exactly what broke andare in the best position to find the problem and fix it. The only thing that couldhave caused the failure was the change we made since the last time the tests ranclean.

All this means is that because the tests are there, we can safely use anotherof the XP practices: refactoring. As we will see in Chapter 2, refactoring is theprocess of making changes to the structure of code without changing its externalbehavior. The tests let you confirm that you haven't changed the behavior. Thisgives you the courage necessary to make (sometimes drastic) changes to workingcode. The result is that the code is cleaner, more extensible, more maintainable,and more understandable.

Appendix A talks a bit more about eXtreme Programming. For more exhaustiveinformation, you can browse the bibliography and explore the onlineXP resources listed in Appendix C.

WHO SHOULD READ THIS BOOK?

Should you read this book? Helping you answer that question is why I wrote thispreface. There was once an informal survey on the XP Yahoo Group as to thepurpose that a preface should serve. The general opinion was that by readingthe preface you should get a good idea of whether you should buy and read thebook. I hope I've done a good job of it!

Read this book if you want to adopt eXtreme Programming. As stated earlier,being able to do TDD well is worth the time and effort it takes to get good atit. TDD is at the heart of XP, so doing TDD well makes the entire process thatmuch more effective.

Read this book if you want to write code that is clearer, more robust, easierto extend, and as slim (as opposed to bloated) as possible.Read this book if you know there must be a better way than spending weeksor months drawing pictures before writing a line of code.

Finally, read this book if you want to know how to make programming funagain.

In terms of what you should know before reading this book, it would help if youhad at least an intermediate understanding of Java. Having a good backgroundin another OO language or two (such as Smalltalk, C++, Python, or Ruby) will,however, enable you to get even more out of this book.

As this book goes to print there is one other TDD book available9 (althoughI'm sure many will follow). I was aware of that book being written as I wrotemuch of this one, and it was always a partial goal to be complementary to it.From it you will get the philosophy and metaphysics of TDD, mixed with enough pragmatics to make it real. If you are so inclined, I encourage you to read it first.

The book you hold in your hands is, as the title says, a practical guide to doingTDD. It's focused on one language (not the best language, but arguably one thatis very popular and well supported for TDD), and presents not only concepts andprinciples, but tools and techniques.

THE STRUCTURE OF THIS BOOK

This book is divided into four parts:

I Background In Part I we examine some topics that relate to the main bodyof material in the book (i.e., TDD in Java). We start with an introductionto TDD. This is followed by chapters on refactoring and programming byintention. These two techniques are also prominent in XP and are requiredand enabled by TDD.

II Tools and Techniques In Part II we take an in-depth look at various toolsthat are useful for practicing TDD with Java, and how to use them. Westart with a tutorial introduction to JUnit, the defacto standard Java TDDframework. We continue by exploring some of the standard (i.e., includedin the distribution) and nonstandard extensions to JUnit. Next, we exploresome tools that support the use of JUnit and other tools that are completelyindependent of JUnit but work well with it. The final chapters in this partexamine specific techniques or issues and the related tools.

III A Java Project: Test-Driven End to End This is a practical hands-onbook. To that end, Part III (which makes up the bulk of the book) is builtaround the development of a real system, not a toy example. We workthrough this project test-first. Along the way we draw on material fromthe previous parts of the book.

IV xUnit Family Members JUnit is just one member of a large and growingfamily of programmer test frameworks. In Part IV we have a look at someof the other members of the family. We don't look at all of them, but wego over several for the more popular languages. So that we get a goodcomparison, we go through the same set of stories (i.e., requirements) foreach. Specifically, these are the initial stories from the Java project. Thislets us compare the various members with JUnit as well.

There are also four appendices:

A eXtreme Programming This appendix provides a very brief introductionto XP.

B Agile Modeling This appendix provides an introduction to and overview ofAgile Modeling.

C Online Resources Throughout the book I refer to Web sites where you canfind information as well as downloads. This appendix contains a categorized,annotated list of these sites.

D Answers to Exercises Many of the chapters in this book contain exercisesfor the reader. This appendix contains all exercises in the book, with answers.

Customer Reviews

Falls short of its goal
This book is about Test-Driven Development (TDD). Its purpose is to help you write better code (by having more tests) and give you a head start with existing tools to achieve this.

The book falls short of these goals: The explanations about writing tests are short on advice and are sometimes misleading. The presentation of the tools is long, with little useful facts.

The book is organized into four parts: Background on TDD, refactoring and programming by intention; A look at JUnit and related tools used to write and run tests; A lengthy example of TDD; An overview of other tools in the xUnit family. The book is targeted at a Java audience but programmers using other languages should have little difficulties understanding the code.

I have a major problem with the background section. The author repeatedly claims that TDD provides exhaustive test coverage and ensures that you can refactor your code with confidence. Any error will be caught by the tests. This is foolish. First, tests rarely reach 100% code coverage. Even the sample that the author provides in the book ends up with less than 90% coverage. This leaves many gaps where tests will fail to detect errors. Even if tests cover 100% branches in the code tests are not exhaustive. Depending on the data used, the same branch may exhibit different behavior. (Not to speak about race conditions and other sources of hard to find bugs.) I fully agree with the author that writing unit tests will improve the quality of the code and help find bugs. But claiming that this is a silver bullet is not wise. I would recommend reading books about tests (e.g., Myers' The Art of Software Testing and McConnell's Code Complete chapter on unit testing) in addition to this book. The section on refactoring is a summary of Martin Fowler's Refactoring book which I recommend.

The second part presents JUnit. JUnit is a framework used to write and run tests. It is a good presentation. However I would have liked to get pieces of advices on what tests to write in addition to how to write them. The author briefly mentions boundary testing but does not have much to say about the tests themselves. Again a test book is invaluable for this. The author recommends using a test coverage tool as well as Jester to measure the tests coverage. This is a great idea.

The third section is an (overly) extended example: the author walks us through writing TDD code. This could have been a great part, giving meaning to the `practical' adjective in the book title. Unfortunately it is a long rambling, showing lots of code but short on insights. The actual `meat' of this part could be summarized in less than five pages.

The last section presents variations on the JUnit tool. Many languages (C++, C#, VB, Python, etc) are discussed. This part would have been better put on a website rather than printed in the book. Given the changes in some of these frameworks the information is obsolete.

The books ends with several appendices dealing with extreme programming and agile modeling.

Unit tests are a great tool to improve code quality. Whether or not you actively practice TDD, a good book on it can provide insights into improving your code. This book contains some interesting bits of wisdom. However much of it is buried by the rest of the material.

Great work covering TDD from the ground up to adv. topics
(Disclaimer: I worked with the author on one large project).
Dave Astels' book is a comprehensive work covering TDD from the ground up to advanced topics. While most of the book examples use Java and JUnit, it does cover unit testing frameworks in several other languages as well. I've read two books on the topic (the other one is Kent Beck's "TDD By Example") and I liked Dave's book better. The basics of TDD can be explained in 10 minutes however when it is applied on practice it gets complicated in at least 3 areas: 1) testing UI 2) testing with database - data setup, isolation, etc. and 3) mocks. Kent's book is more about a philosophy of TDD but it only goes through a very simple "toy" example. Dave's book really helped me to understand mocks and it does cover UI testing in great length. Mocks are an advanced topic, so it does require a good knowledge of Java and OOP. The rest of the book seems to be on intermediate technical level.

The only thing this book is missing, I think, is a discussion about data setup and database-related testing, dbUnit, etc., other than an advice to avoid it altogether (p. 83). While you can indeed use mocks to avoid it, on the large real projects some kind of integration testing (including testing with the database) will be necessary. I hope the second edition will come out at some point!

Overall, it's a great book for both newcomers and developers with unit testing experience. BTW, it won SD West 2004 Jolt Award.

A practical guide to test-driven development
Test-driven development (TDD) is one of the hot topics in the recent "agile revolution". Unfortunately, there aren't too many texts currently available that take an in-depth look at the subject. David Astels jumps into the fray with his new book, "Test-Driven Development: A Practical Guide", in order to help fill that void. Giving a nod to Kent Beck's "Test Driven Development By Example", Astels views his work as a complement to Beck's, focusing on the practical techniques and tools necessary to best make use of TDD.

The book first touches on some topics fundamental to TDD, such as refactoring, programming by intention, and of course the basic theory behind TDD. Appendices further flesh out this material by addressing extreme programming and agile modeling.

Although other members of the xUnit family are looked at, this book is squarely focused on JUnit and Java. As such, the text goes into detail about using JUnit, including the API, and how to go about the task of writing tests. Along with the JUnit coverage, the reader is presented with information on several JUnit extensions and JUnit related tools designed to aid the TDD process. Where this book really shines is in its coverage of mock objects and techniques for testing GUIs within JUnit.

The meat of this book rests in a very detailed walkthrough of a project using TDD. Astels leads the reader through every test and every refactoring along the way, from inception to the finished product. This is probably the next best thing to sitting down for a pair-programming session with a TDD guru.

Unfortunately, there are a couple of complaints I feel the need to point out. The project presented is a Swing application that persists its data in a flat file. There is no coverage provided for testing web based enterprise applications. While mention is made of DatabaseChecker, a test utility suitable for simple database tests, Astels chose not to have the example project use a database for persistence. As a consequence of this decision, this common task is left unaddressed.

Despite these omissions, there is still much to be gained from this book. I feel a reader may obtain the most benefit by downloading the sample code and working through the example project step-by-step along with the text. If you are interested in a practical guide to TDD, this book is definitely worth a look.