TDD in the Real World

1
TDD in the Real World
Perry Hertler Technical Software Architect
2
Agenda

• Why TDD?
• Quick review
• Short demo
• Benefits
• Longer demo
• Tips
• TDD vs TAD
• Questions?

3
Why TDD? High level

• The earlier you fix a bad design the cheaper it
  is
• The earlier you fix a bug the cheaper it is
• A necessity for iterative and incremental
  development is constant refactoring, which cannot
  be done correctly without sufficient test coverage

4
Why TDD? - Less Defects (Design Code)
5
TDD - Stages
Compile
Write a test
Fix compile errors
Run test, watch it fail
Refactor code (and test)
Run test, watch it pass
Write code
6
Simple Definition

• Only write code that makes a test pass

7
TDD Demonstration (short)

• Story summary I as an end-user want to create a
  secure password.
• Acceptances
• Password must be between 10 and 15 characters
• Password must contain at least one numerical
  character

8
Agenda

• Why TDD?
• Quick review
• Short demo
• Benefits
• Longer demo
• Tips
• TDD vs TAD
• Questions?

9
TDD - Benefits

• Forces one to think about how the code will be
  used first. "The act of writing a unit test is
  more an act of design than of verification", Bob
  Martin.
• Finds bugs early or prevents them altogether
• Refactor with confidence knowing that the code is
  protected
• Thinking of and designing for edge cases up front
  leads to a better and more stable design

10
TDD Benefits

• Efficient in that youre only writing code to
  satisfy the requirements and no more.
  (DTSTTCPW)
• Reduces reliance on debugger
• The tests document system behavior
• Necessarily leads to testable code

11
TDD Demonstration (long)

• Story summary I as a sudoku cheater want to
  enter an incomplete sudoku puzzle and have the
  system solve it for me.
• Acceptances
• End user enters incomplete puzzle then the system
  solves it
• Puzzles with more than one solution should
  display just one correct solution
• User provided numbers will have a white
  background and be read-only after solving
• Calculated number will have a green background
  and be read-only after solving
• Only number 1 through 9 are allowed

12
Agenda

• Why TDD?
• Quick review
• Short demo
• Benefits
• Longer demo
• Tips
• TDD vs TAD
• Questions?

13
Tips

• Small steps
• Tests should not be broken for more than a few
  minutes
• Testable code
• Dependency injection
• Avoid singletons and static methods
• Separation of concerns
• Favor composition over inheritance
• Refactor
• Mercilessly refactor
• Even refactor tests
• DRY, Single-responsibility rule

14
Tips

• Keep tests focused, atomic, and isolated
• Stub irrelevant
• When fixing a defect, first write a test that
  exposes it

15
Best ways to learn TDD

• Do it
• Pair with an expert
• Test Driven TDD and Acceptance TDD for Java
  Developers, Koskela

16
Bad smells

• A code change breaks many tests
• The same boiler plate code is repeated over and
  over
• Order of tests should not matter
• Its just test code

17
TDD vs TAD Shortcomings of TAD

• Does not protect the code while in development
• The intent of the code may not be remembered so
  thinking of edge cases is more difficult
• Difficult to test classes that are not designed
  to be testable

18
TDD vs TAD Shortcomings of TAD (cont)

• Testing after does not help the design
• Most TAD projects just test the complex parts
  of code
• Execution of TAD is generally an after-thought,
  which concerns itself mostly with code coverage

19
Agenda

• Why TDD?
• Quick review
• Short demo
• Benefits
• Longer demo
• Tips
• TDD vs TAD
• Questions?