Test Driven Development

Red
Green
Refactor!

Red

  • Write a failing test

  • See it fail in the way you expect

Green

  • Make the test pass

  • Do this in the simplest possible way

Refactor!

Make the code good

  • Remove Duplication
  • Reduce coupling (connascence)
  • SOLID
  • Clean Code

TDD as if you mean it

  • Write one test at a time
  • Write methods / functions to make the test pass  within the test file
  • Extract "production" classes only when confident a good structure is emerging
  • "Listen to the tests"

Pairing Ping Pong

  • Person A writes a failing test

  • Person B makes it pass and refactor

  • Switch and repeat

Code Kata

  • Improve through repetition / practice

  • http://codekata.com/

  • Experiment with constraints (Object Calisthenics, No Ifs etc.)

Checkout Kata

  • Model supermarket checkout

  • Scan items and calculate total price

  • Allow for multi-buy offers

  Item   Unit      Special
         Price     Price
  --------------------------
    A     50       3 for 130
    B     30       2 for 45
    C     20
    D     15

From codekata.com - google "checkout kata"

Thoughts?

TDD is a design discpine

  • Encourages Decoupling

  • Interface Focused

  • YAGNI compliant

  • Developer Confidence / Happiness
  • Ability to change (design and coverage)
  • Documentation
  • Reduce need to debug

Other Benefits

 

#IsTDDDead

 

  • Test Induced Design Damage
  • Replaced Thoughtfulness
  • Applicability to Functional Programming
  • Types of problems caught
  • Coverage Over-Confidence
  • Too many tests

Related Practices

 

  • Behavior Driven Development

  • Property Based Testing

Good Reads

  • TDD by Example - Kent Beck
  • Refactoring - Martin Fowler
  • Growing Object Oriented Software, Guided by Tests - Steve Freeman & Nat Pryce
  • Silk and Spinach blog - Kevin Rutherford
Made with Slides.com