Kent Beckconsistently 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.
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
more >>
Kent Beckconsistently 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.
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:
Solve complicated tasks, beginning with the simple and proceeding to the more complex.Write automated tests before coding.Grow a design organically by refactoring to add design decisions one at a time.Create tests for more complicated logic, including reflection and exceptions.Use patterns to decide what tests to write.Create tests using xUnit, the architecture at the heart of many programmer-oriented testing tools.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 Developmentis sure to inspire readers to embrace these under-utilized but powerful techniques.
0321146530B10172002
Clean code that works,in Ron Jeffries' pithy phrase, is the goal of Test-Driven Development (TDD). Clean code that works is a worthwhile goal for a whole bunch of reasons.
It is a predictable way to develop. You know when you are finished, without having to worry about a long bug trail.It gives you a chance to learn all of the lessons that the code has to teach you. If you only slap together the first thing you think of, then you never have time to think of a second, better thing.It improves the lives of the users of your software.It lets your teammates count on you, and you on them.It feels good to write it.But how do we get to clean code that works? Many forces drive us away from clean code, and even from code that works. Without taking too much counsel of our fears, here's what we do: we drive development with automated tests, a style of development called Test-Driven Development (TDD). In Test-Driven Development, we
Write new code only if an automated test has failedEliminate duplicationThese are two simple rules, but they generate complex individual and group behavior with technical implications such as the following.
We must design organically, with running code providing feedback between decisions.We must write our own tests, because we can't wait 20 times per day for someone else to wri
<< less
MY CART | item(s)
U.S. Standard
Free U.S. Standard
U.S. Expedited
International
