Test Driven Development: By Example 1st Edition
|
Kent Beck
(Author)
Find all the books, read about the author, and more.
See search results for this author
|
Use the Amazon App to scan ISBNs and compare prices.
Frequently bought together
Customers who viewed this item also viewed
What other items do customers buy after viewing this item?
Editorial Reviews
From the Back Cover
Clean code that works--now. This is the seeming contradiction that lies behind much of the pain of programming. Test-driven development replies to this contradiction with a paradox--test the program before you write it.
A new idea? Not at all. Since the dawn of computing, programmers have been specifying the inputs and outputs before programming precisely. Test-driven development takes this age-old idea, mixes it with modern languages and programming environments, and cooks up a tasty stew guaranteed to satisfy your appetite for clean code that works--now.
Developers face complex programming challenges every day, yet they are not always readily prepared to determine the best solution. More often than not, such difficult projects generate a great deal of stress and bad code. To garner the strength and courage needed to surmount seemingly Herculean tasks, programmers should look to test-driven development (TDD), a proven set of techniques that encourage simple designs and test suites that inspire confidence.
By driving development with automated tests and then eliminating duplication, any developer can write reliable, bug-free code no matter what its level of complexity. Moreover, TDD encourages programmers to learn quickly, communicate more clearly, and seek out constructive feedback.
Readers will learn to:
This book follows two TDD projects from start to finish, illustrating techniques programmers can use to easily and dramatically increase the quality of their work. The examples are followed by references to the featured TDD patterns and refactorings. With its emphasis on agile methods and fast development strategies, Test-Driven Development is sure to inspire readers to embrace these under-utilized but powerful techniques.
0321146530B10172002
About the Author
Kent Beck consistently challenges software engineering dogma, promoting ideas like patterns, test-driven development, and Extreme Programming. Currently affiliated with Three Rivers Institute and Agitar Software, he is the author of many Addison-Wesley titles.
Product details
- ASIN : 0321146530
- Publisher : Addison-Wesley Professional; 1st edition (November 8, 2002)
- Language : English
- Paperback : 240 pages
- ISBN-10 : 9780321146533
- ISBN-13 : 978-0321146533
- Item Weight : 14.1 ounces
- Dimensions : 7.38 x 0.55 x 9.25 inches
-
Best Sellers Rank:
#62,839 in Books (See Top 100 in Books)
- #34 in Software Design & Engineering
- #35 in Software Testing
- #108 in Software Development (Books)
- Customer Reviews:
I'd like to read this book on Kindle
Don't have a Kindle? Compra tu Kindle aquí, or download a FREE Kindle Reading App.
About the author

Kent Beck is the founder and director of Three Rivers Institute (TRI). His career has combined the practice of software development with reflection, innovation, and communication. His contributions to software development include patterns for software, the rediscovery of test-first programming, the xUnit family of developer testing tools, and Extreme Programming. He currently divides his time between writing, programming, and coaching. Beck is the author/co-author of Implementation Patterns, Extreme Programming Explained: Embrace Change 2nd Edition, Contributing to Eclipse, Test-Driven Development: By Example, Planning Extreme Programming, Smalltalk Best Practice Patterns, and the JUnit Pocket Guide. He received his B.S. and M.S. in Computer Science from the University of Oregon.
Customer reviews
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
I can pretty much deal with the chummy style of writing, but "keeping it light" doesn't work when I'm digging for information. I found the mindlessly simplistic initial case study to be more of a distraction than aid. When it takes that many pages, false starts, side trips, and retries to add two numbers, whatever point was being made gets lost in the vapid example used to make it. (We can skip the fact that, as the author notes, the number format being used is poorly suited to the nominal problem domain.)
Then, given that the whole book is about software testing I find it odd that there's little to no direct mention of a central question: what makes software testable or not? "Design for testability" has been a topic in the hardware world for a half-century, give or take. But, even with the software world's relatively recent attention to testing and even with dogmatic manifestos like this, I have not found any body of knowledge or practice that addresses the topic systematically.
Machinists talk about what makes an alloy machinable. Farmers know what make land farmable. Woodworkers can specify what makes a wood workable. Seemingly everyone knows what makes their subject material better or worse for their purpose and can tell you in detail. Everyone except software testers, apparently. This book discusses practice without actually saying what it practices on, and leaves me feeling that I heard only half of a conversation.
This is going to the used market as fast as I can fling it.
-- wiredweird
It is a shame that we are disallowed from giving the publisher (or whoever creates the Kindle formatting) a separate rating from the author. Author maybe 5 star, publisher/formatter 1 star.
By Nunya Bidness on June 2, 2021
It is a shame that we are disallowed from giving the publisher (or whoever creates the Kindle formatting) a separate rating from the author. Author maybe 5 star, publisher/formatter 1 star.
Where I disagree is in the use of the tests to drive software design. In the first part of the book, which I think is the most important part, a very good coding problem is analyzed - it is realistic, limited in scope and far from trivial. I followed along until I reached a point where things stopped making sense. I skipped ahead to see where things were headed and then things became clear.
What is being advocated is a type of bottom up design approach. This may work for some. It may even be that the book faithfully reproduced Beck's reasoning process. It does not work for me. I first have to see the larger picture, what he refers to as the "metaphor." The whole thing would have been much clearer to me if at the beginning I was told that one approach to summing money in different currencies would be to use an array to store the information but that instead the implementation would create a list similar to how things are done in LISP.
I urge the reader to judge for him/herself. Like I said this is a good example to go through. I even learned some things about more advanced uses of object oriented programming. As for software design I am going to stick with dataflow diagrams. They are still the best tool that I know of for putting together software, UML notwithstanding.
I've read it many times and still learn form it today. The short chapters gives the reader a flow that is unique, like TDD baby steps.
Top reviews from other countries
My biggest gripe with this book was that it is just too simple for practical use. If it covered testing API calls, database interactions, some front end tests, user management, Web Host configuration and complex, real world tasks like that then I'd give this book 5 stars. No one uses a Money object with a Times() function in real life.









