| ||||||||||||||||||
![]() Trade In this Item for up to £6.90
Get an extra £5 when you trade in books worth £10 or more until June 30, 2012. Trade in Test Driven Development (The Addison-Wesley Signature Series) for an Amazon.co.uk gift card of up to £6.90, which you can then spend on millions of items across the site. Trade-in values may vary (terms apply). Find more products eligible for trade-in.
|
Product details
|
Quite simply, test-driven development is meant to eliminate fear in application development. While some fear is healthy (often viewed as a conscience that tells programmers to "be careful!"), the author believes that byproducts of fear include tentative, grumpy, and uncommunicative programmers who are unable to absorb constructive criticism. When programming teams buy into TDD, they immediately see positive results. They eliminate the fear involved in their jobs, and are better equipped to tackle the difficult challenges that face them. TDD eliminates tentative traits, it teaches programmers to communicate, and it encourages team members to seek out criticism However, even the author admits that grumpiness must be worked out individually! In short, the premise behind TDD is that code should be continually tested and refactored. Kent Beck teaches programmers by example, so they can painlessly and dramatically increase the quality of their work.
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.
Tags Customers Associate with This Product(What's this?)Click on a tag to find related items, discussions, and people.
|
Perhaps you will feel differently, but I like the book simply because it is short. Huge computing textbooks that cram in too much information annoy me; I rarely have the time to read through such huge tomes or absorb everything they are trying to tell you in one sitting. I was able to read the first part of this book, and attain a reasonable understand of TDD in just over 2 hours.
The book is not terribly expensive either, and sets the stage for further reading on TDD and agile methodologies in general.
I would recommend this book if you are at all interested in TDD.
This book is in 4 sections, each of which would be a magazine article for any other author:
1. A tiring, trivial example of TDD strung out over a staggering 80 pages in normal Kent-Beck-six-sentences-per-page style.
2. An overview of JUnit, bizarrely documented in Python. Nothing against Python but what's the point when the aim is to understand JUnit, not get a taster in a new language?
3. An brief overview of Design Patterns
4. An brief overview of Refactoring
There is very little new in this book and even less to help with doing it on a real project.
But wait! Before I'm branded an unthinking curmudgeon it's not all bad; for those who have pondered the vexing issue of how to add a parameter to a method then tucked away on page 190 I found this pearl of wisdom:
1. If the method is an interface, add the parameter to it.
2. Add the parameter to the method
3. Use the compiler to show you the calls that need changing
Well what can I say...eureka? Thanks for that Kent, I'll raise it at my next developer meeting but tell'em I thought of it, they'll think me a genius.
How Addison Wesley can put this book in the same class as Martin Fowler's stuff is a mystery, the Fowler books contain more information in the Preface.
|