Learn Test Driven Development

Learn Test Driven Development

Fran Iglesias and Óscar Iglesias González
Buy on Leanpub
Table of Contents

Prologue›

    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›

      Learn Test Driven Development/