# Book Review: TDD by Example

Good books are worth re-reading. I have read TDD by Example at least three times. The book has many practical examples. It showcases the Test Driven Development(TDD) discipline in an effortless and funny style. This book has advanced my career like no other.

The Author

Kent Beck was one of the creators of the Agile Manifesto. He is the creator of the Test Driven Development discipline. He has also collaborated in other classics such as Extreme Programming Explained and Refactoring.

Part I and II: Examples

The book solves traditional computing problems with a Test Driven approach. These two sections showcase how to practice the discipline to achieve optimal results. Using static or dynamic languages. Code analysis tools reveal the astounding quality of the produced code. The examples show how the tests can drive the design into more expressive and maintainable solutions.

Stress

The book mentions stress many times. Do you recognize any of these?

Scenario 1: “We’re in a hurry we don’t have time to write tests”. Hurried changes without tests produce bad software. Bad software produces more stress.
Mitigation: Write more tests. More tests increase the quality of the software. Good software is easy to change and has almost no defects.

Scenario 2: “This design will cover all the requirements. It is complex. But perfect.” Three weeks later. “What do you mean requirements changed? How do I fit that into what I have?”
Mitigation: Software always changes. Requirements change. Embrace change. Practice Test Driven Development and change will be easier.

Scenario 3: “I have to do these 20 things for this feature. Internationalization?! Now I have to do 21”. Restroom break. “Where was I in the 15 things to do?”
Mitigation: Write down all the things to do. Add new tasks to the list as they come. Work through that list one step at a time. Nothing will ever be forgotten.

The Test Driven Development discipline is about focusing on one task at a time. The book shows how anything else should be written down in a list and dealt with later. This practice reduces stress levels and increases productivity.

Part III: Patterns

The third part of the book is dedicated to design and testing patterns. How to write and design tests. The need for isolated, independent and easy to comprehend tests. How to leverage tests to understand the behavior of dependencies.

Rapid Feedback

An important benefit of the TDD discipline is the shortening of feedback cycles. Rapid feedback lets you know when you’re moving in the right direction. Large changes need decomposition to achieve rapid feedback. This practice enhances the design.

Refactoring

Design is rarely created in a perfect way. It needs to evolve through countless changes. TDD empowers the constant refactoring flow mandated by changing requirements. The book showcases several refactoring patterns. It also covers the need to write tests before refactoring untested code. I recommend Refactoring -by Martin Fowler- for a deep dive on the topic.

Mastering TDD

The final chapter contains invaluable information for those learning the discipline.

• What don’t you have to test?
• How do you know if you have good tests?
• How much feedback do you need?
• When should you delete tests?
• Can you test drive large systems?
• Can you drive development with application-level tests?
• How do you switch to TDD midstream?
• Who is TDD intended for?
• Is TDD sensitive to initial conditions?
• How does TDD relate to patterns?
• Why does TDD work?
• How does TDD relate to the practices of Extreme Programming?

Should you read it?

Definitely. TDD by Example will not only help you become a better software engineer. The book explains tools to manage any type of work.