Introduction to Software Verification

1
Introduction to Software Verification

• Test-Driven Development (TDD)

2
What is TDD?

• An iterative technique for developing software
• As much about good design as testing
• Encourages design from a users point of view
• Encourages testing classes in isolation
• Produces loosely-coupled, highly-cohesive systems

Grenning
3
What is TDD?

• Must be learned and practiced
• If it feels natural at first, youre probably
  doing it wrong
• Can be more productive than debug-later
  programming
• Its an addiction rather than a discipline Kent
  Beck

Grenning
4
Cohesion and coupling

• Each module should be highly cohesive
• module understandable as a meaningful unit
• components of a module are closely related to one
  another
• Modules should exhibit low coupling
• modules have low interactions with others
• understandable separately

5
A visual representation
high coupling, low cohesion
low coupling, high cohesion
6
TDD Mantra Red / Green / Refactor

• Red Write a little test that doesnt work, and
  perhaps doesnt even compile at first.
• Green Make the test work quickly, committing
  whatever sins necessary in the process.
• Refactor Eliminate all of the duplication
  created in merely getting the test to work.

Beck
7
TDD Development Cycle
Start
Write a test for a new capability
Compile
Refactor as needed
Fix compile errors
Run all teststo see them pass
Run the test and see it fail
Write the code
Grenning
8
Do the Simplest Thing

• Assume simplicity
• Consider the simplest thing that could possibly
  work
• Iterate to the needed solution
• When Coding
• Build the simplest possible code that will pass
  the tests
• Refactor the code to have the simplest design
  possible
• Eliminate duplication

Grenning
9
TDD Process

• Once a test passes, it is re-run with every
  change
• Broken tests are not tolerated
• Side-effects defects are detected immediately
• Assumptions are continually checked
• Automated tests provide a safety net that gives
  you the courage to refactor

Beck
10
TDD Process

• What do you test?
• everything that could possibly break
• - Ron Jefferies
• Dont test anything that could not possibly break
  (always a judgment call)
• Example Simple accessors and mutators

Beck
11
TDD Process

• Start small or not at all (select one small piece
  of functionality that you know is needed and you
  understand)
• Ask what set of tests, when passed, will
  demonstrate the presence of code we are confident
  fulfills this functionality correctly?
• These are our test heuristics.
• Make a to-do list, keep it next to the computer
• Lists tests that need to be written
• Reminds you of what needs to be done
• Keeps you focused
• When you finish an item, cross it off
• When you think of another test to write, add it
  to the list

Beck
12
Test Selection

• Which test should you pick from the list?
• Pick a test that will teach you something and
  that you are confident you can implement.
• Each test should represent one step toward your
  overall goal.
• How should the running of tests affect one
  another?
• Not at all isolated tests.

Beck
13
Assert First

• Where should you start building a system?
• With the stories you want to be able to tell
  about the finished system.
• Where should you start writing a bit of
  functionality?
• With the tests you want to pass on the finished
  code.
• Where should you start writing a test?
• With the asserts that will pass when it is done.

Beck
14
Continuing

• Fake It (Til You Make It)
• Triangulate
• Obvious Implementation

Beck
15
Fake It (Til You Make It)

• What is your first implementation once you have a
  broken test?
• Return a constant
• Once you have a test running, gradually transform
  the constant into an expression using variables.

Beck
16
Triangulate

• How do you most conservatively drive abstraction
  with tests?
• Abstract only when you have two or more examples.

Beck
17
Triangulate

• Test 1
• public void testSum()
• assertEquals(4, plus(3,1))
• Code
• private int plus(int augend, int addend)
• return 4
• Test 2
• public void testSum()
• assertEquals(4, plus(3,1))
• assertEquals(7, plus(3,4))

Beck
18
Obvious Implementation

• How do you implement simple operations?
• Just implement them
• Fake It and Triangulation are for taking tiny
  steps.
• If you know what to type, and you can do it
  quickly, then do it.
• Keep track of how often you are surprised by red
  bars using Obvious Implementation.

Beck
19
Obvious Implementation

• Solving clean code at the same time that you
  solve that works can be too much to do at once.
  As soon as it is, go back to solving that
  works, and then clean code at your leisure.
• Kent Beck

Beck
20
After the first cycle you have

• Made a list of tests we knew we needed to have
  working.
• Told a story with a snippet of code about how we
  wanted to view one operation
• Made the test compile with stubs
• Made the test run by committing horrible sins
• Gradually generalized the working code, replacing
  constants with variables
• Added items to our to-do list rather than
  addressing then all at once

Beck
21
Refactoring

• Usually, refactoring cannot change the semantics
  of the program under any circumstance.
• All test that pass before refactoring must pass
  after refactoring.
• Observation equivalence places burden on you to
  have enough tests to detect unintended behavioral
  changes due to refactoring.

Beck
22
Refactoring - Levels of Scale

• Two loop structures are similar. By making them
  identical, you can merge them.
• Two branches of a conditional are similar. By
  making them identical, you can eliminate the
  conditional.
• Two methods are similar. By making them
  identical, you can eliminate one.
• Two classes are similar. By making them
  identical, you can eliminate one.

Beck
23
Reading More

• Article by Robert C. Martin and Robert S. Koss on
  test driven development of bowling scoring code.
• http//www.objectmentor.com/resources/articles/xpe
  pisode.htm

Beck
24
References

• Test-Driven Development by Example by Kent Beck,
  Addison Wesley 2003. ISBN 0-321-14653-0.
• Grenning, James W. Test-Driven Development and
  Acceptance Testing, 10/05/2003,
  www.uniforum.chi.il.us/slides/testdrivendevel/TDD.
  pdf