Test Driven Development (TDD)

1
Test Driven Development (TDD)

• Presented by
•  
•  
• Victor Goldberg, Ph.D.

2
The Nature of our Problem
Then a miracle occurs
Good work, but I think we need more detail right
here.
3
What is Test Driven Development?

• Its a practice that adds reliability to the
  development process.

4
Why is TDD important?

•  Many projects fail because they lack a good
  testing methodology.
•  
• Its common sense, but it isnt common practice.
• The sense of continuous reliability and success
  gives you a feeling of confidence in your code,
  which makes programming more fun.

5
How does it work?

• Have a requirement. Lets say create a new
  random card, as for a card game.
• Think about what could be a reasonable test to
  verify compliance with the requirement.
• Write the test before writing the code. Of
  course, the test will fail, and thats ok.
• Keep things simple.
• Then, write only the minimally necessary code to
  make the test pass.
• This is a process of discovery as you identify
  possible improvements, refactor your code
  relentlessly to implement them.
• Build, keep, and frequently run your cumulative
  collection of tests.

6
There are different kinds of tests

• Experiments (a.k.a. spikes),
• Acceptance tests,
• Code Behavior tests, and
• Development code TDDs main functional
  tests realm.
•   We will also touch on experiments.

7
A Possible Initial TDD Test(in Smalltalk ST)

• testCardDrawnIsWithinRange
• number
•  
• number card draw numericalValue .
• self assert ( number gt 0 ) ( number
  lt 14 ) .

Method Name
Local variable
Getter retrieves a result of the action
Action
Object
8

• Fig 1. The same code in the ST
  browser. 
• card is in red because the system doesnt
  recognize such an object.
• self is an instance of the class TestCards.
• assert is a message sent to self its
  argument is a Boolean.
• TestCards is a child of TestCase, a class in
  the SUnit framework.

9

• Fig 2. When run, the test identifies an error.
•  
• The assertion didnt have the opportunity to
  fail, because an error was identified before the
  assertion was applied.

10
(The Card class)

• Fig 3. The Card class and card instance are
  created.
• The new instance of Card is assigned to the
  variable card.

(The card instance)
11

• Fig 4. The test still identifies an error. 
• The card instance doesnt recognize the method
  draw.
• Designing draw requires some skill.
• We will develop the skill through an experiment.

12
Experiment Example in the Smalltalk Workspace

• r Random new . frequency Bag
  new. "Variables typing"
• 1 to 1000000
• do index result  
• result (r next 13) floor 1.
• result gt0 result lt 14
• ifTrue frequency add result
• ifFalse Dialog warn 'Result out of
  range' .
• .
• frequency contents.
• Fig. 5 The ST Workspace is like scratch paper, a
  place to experiment.
•  
• The experiment here is to find whether our
  formula for random numbers is acceptable.

13

• Fig 6. The results of running the code twice.
• The distribution of values is in the same range
  for each outcome, but different for each run.
  All are within 1, 13. So, we are confident
  that our coding of the math is correct.

14

• Fig 7. After the experiment we feel comfortable
  writing draw.
• In draw we assign the result of the calculation
  to the instance variable numericalValue

15

• Fig 8. Now the test passes.
•  
• In this case numericalValue is a getter, a
  message sent to the card object to retrieve the
  contents of the instance variable numericalValue.

16
TDD is fun!!!

• Passing the test
• (the green bar)
• is the feedback
• that makes it fun.
•  
•  

17
Summary
18
Summary (1)

• In TDD
• Requirements drive the tests.
• Tests drive the development of the application
  code.
• No application code is written without writing a
  failing test first.
• Tests are collected in a suite and the suite is
  run frequently, like every time after code is
  written.
• Test and code are written in elementary
  increments.
• Refactoring is a continuous operation, and is
  supported by a passing battery of tests.

19
Summary (2)

• TDD is good because it
• Reduces the number of bugs by orders of
  magnitude,
• Increases development speed, because less time is
  spent chasing bugs.
• Improves code quality because of the increased
  modularity, and continuous and relentless
  refactoring.
• Decreases maintenance costs because the code is
  easier to follow.

20
Summary (3)

• In addition to all its technical contributions
  to a project,
•  
• Test Driven Development succeeds because

21

I t ' s F u n ! ! !