Learn Test Driven Development
Minimum price
Suggested price

Learn Test Driven Development

English Edition

About the Book

Book to help to learn TDD, with several proposals of sequenced katas to address several details of the methodology. Katas are organized in formulation, resolution examples and a complete explanation of the main point illustrated with the exercise.

This book is a translation into English of Aprende Test Driven Development which was originally written in Español.

About the Authors

Fran Iglesias
Fran Iglesias

Soy un desarrollador backend que trabaja sobre todo con PHP, aunque no dejo de explorar y probar otros lenguajes. Me interesan mucho las buenas prácticas, especialmente el testing y el test/behavior driven development.

Óscar Iglesias González
Óscar Iglesias González

¡Hola! Soy un practicante de ciencia de datos y desarrollador, interesado en buenas prácticas y código limpio, especialmente en el contexto del machine learning. Me apasionan aprender y compartir lo aprendido. :)

Table of Contents

  • Prologue
      • How to use this book
      • Disclaimer
  • Basic TDD concepts
    • What is TDD and why should I care about it?
      • The Test Driven Development methodology
      • What is not Test Driven Development
      • Benefits
      • References
    • Basic concepts
      • Test
      • Types of tests
      • Test Case
      • Test Suite
      • Production code
      • Software unit
      • Subject under test
      • Refactoring
    • Coding-dojo y katas
      • Kata
      • Coding-dojo
      • Advice for completing the kata individually
      • How to introduce TDD in development teams
      • Kata repositories
      • References
  • Classic TDD
    • The laws of TDD
      • The laws in detail
      • The second test and the three laws
      • Violations of the three laws and their consequences
      • What does it mean if a test passes just after writing it?
      • The red-green-refactor cycle
      • References
    • Fizz Buzz
      • Understanding the laws and cycles of TDD
      • History
      • Problem statement
      • Hints to solve it
      • Links of interest about the FizzBuzz kata
    • Solving the Fizz Buzz kata
      • Statement of the kata
      • Language and focus
      • Define the class
      • Define the generate method
      • Define a behavior for generate
      • Generate a list of numbers
      • We keep generating numbers
      • The test that doesn’t fail
      • Learning to say “Fizz”
      • Saying “Fizz” at the right time
      • Learning to say “Buzz”
      • Saying “Buzz” at the right time
      • Learning to say “FizzBuzz”
      • Saying “FizzBuzz” at the right time
      • Wrapping up
      • What have we learned in this kata
    • Selection of examples and finalization criteria
      • Checklist driven testing
      • Example selection
      • Using many examples to generalize an algorithm
      • In search of the wrong abstraction
      • The correct abstraction
    • Evolution of the behavior through tests
      • Constructing the public interface of a test driven class
      • Drive the development of a behavior through examples
      • References
    • Prime Factors
      • Introduction
      • History
      • Problem statement
      • Hints to solve it
      • Links of interest about the Prime Factors kata
    • Solving the Prime Factors kaka
      • Statement of the kata
      • Language and approach
      • Define the function
      • Define the function’s signature
      • Obtaining more imformation about the problem
      • Introducing a test that doesn’t fail
      • Questioning our algorithm
      • Discovering the multiples of 2
      • Introducing more factors
      • New divisors
      • The shortest path isn’t always the fastest
      • Introducing new factors, second try
      • More than two factors
      • Do we have any criteria to select new examples?
      • What have we learned in this kata
    • The choice of the first test
      • In search of the simplest test that can fail
      • The happiness of the paths
    • NIF
      • Start with the sad paths and postpone the solutions
      • History
      • Problem statement
      • Hints to solve it
      • Links of interest about the kata
    • Solving the NIF kata
      • Statement of the kata
      • Language and focus
      • Create the constructor function
      • Implement the first validation
      • A test to rule them all
      • Complete the validation of the length and start examining the structure
      • The not very clean way of changing the test and production code a the same time
      • Unify the string length validation
      • Moving forward with the structure
      • Invert the conditional
      • The end of the structure
      • Compacting the algorithm
      • Finishing the structural validation
      • Compacting the validation
      • Let’s look on the bright side
      • Changing the public interface
      • NOW it’s time
      • Moving forward with the algorithm
      • More refactoring
      • Validating more control letters
      • A refactoring, for even more simplicity
      • NIE support
      • What have we learned in this kata
      • References
    • The refactoring phase
      • The function of refactoring in TDD
      • Which refactorings to do
      • Refactoring limits
      • When is the right moment to refactor
    • Bowling game
      • The refactoring phase
      • History
      • Problem statement
      • Hints to solve it
      • Links of interest about the Bowling Game kata
    • Solving the Bowling Game kata
      • Statement of the kata
      • Language and approach
      • Starting the game
      • Let’s throw the ball
      • Time to refactor
      • Counting the points
      • The world’s worst thrower
      • Organizing the code
      • Teaching our game to count
      • A step back to reach further
      • Recovering a cancelled test
      • Getting more comfortable
      • How to handle a spare
      • Introducing the concept of frame
      • Continue handling spare
      • Removing magic numbers and other refactorings
      • Strike!
      • Reorganizing the game knowledge
      • The world’s best player
      • What have we learned in this kata
    • Greetings
      • A functional kata to rule them all
      • History
      • Problem statement
      • Hints to solve it
      • Links of interest about the Greetings kata
    • Solving the Greetings kata
      • Statement of the kata
      • Language and approach
      • Basic greeting
      • Generic greeting
      • Use the parameter
      • Back to the generic greeting
      • Answering with a yell
      • Be able to greet two people
      • Getting ready for several names
      • A refactoring before proceeding
      • Reintroducing a test
      • Handle an indeterminate amount of numbers
      • Shout to the shouters, but only to them
      • Separate names that contain commas
      • Escaping commas
      • What have we learned in this kata
  • Outside-in TDD
    • TDD approaches
      • Classic TDD or Detroit School
      • Outside-in, London School or mockist
      • Behavior Driven Development
      • So, what approach should we follow? And how do we learn TDD under the light of these approaches?
      • References
    • To-do list project
      • Design
    • Mockist outside-in
      • Development
      • Designing the acceptance test
      • First unit test
      • Back to the acceptance cycle
      • New visit to the acceptance test
      • Finishing the first user story
      • Last steps
      • What have we learned in this kata
    • Classic outside-in TDD
      • Posing the problem
      • Extraction of the use case
      • Implementing a repository
      • Obtaining the to-do list
      • Mark a task as completed
      • What have we learned in this kata
  • TDD in real life
    • Task list, outside-in TDD sliced in user stories
      • Adding task to a list
      • Designing in red
      • Returning to the acceptance test
      • New cycle
      • See the tasks on the list
      • Checking completed tasks
      • Next steps
    • Fixing bugs with TDD
      • To-do list bugs
      • Invalid payload
      • Invalid business values
      • Guaranteeing business rules
      • Not found tasks
      • Solving defects
    • Adding new features
      • New user story
      • Complete the story
  • Epilogue
    • TDD and quality of life (yours)
      • Knowledge in the world, knowledge in the head
      • The capacity of our working memory
      • A day in the life
      • A final piece of advice
  • Notes

The Leanpub 45-day 100% Happiness Guarantee

Within 45 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

See full terms

Do Well. Do Good.

Authors have earned$10,913,181writing, publishing and selling on Leanpub, earning 80% royalties while saving up to 25 million pounds of CO2 and up to 46,000 trees.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets) and MOBI (for Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF, EPUB and/or MOBI files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub