Functions 5.

1
Functions 5.

• 1. Stubs and drivers.
• 2. Unit testing and integration testing.
• 3. In-class/review.

2
1. Stubs and drivers.

• Key idea of testing programs with functions
• The building block approach.
• Using functions, (1) one can build programs block
  by block and (2) one can test each block before
  going on to the next block.
• See diagrams.

3
Stubs and drivers (cont.).

• Why do it this way?
• As much as possible we can eliminate errors
  before moving on to the next stage. Like a
  builder who wants to be sure the foundation is
  sound, then the walls, then the roof.
• If an error is found at a later stage, it was
  probably caused by a later module.

4
Stubs and drivers (cont.).

• But, how can we test individual functions?
• Need to be able to run functions independently.
• This uses the idea of stubs and drivers.
• First create a driver a skeleton main program
  that can be used to call just the function(s) you
  want to test.

5
Stubs and drivers (cont.).

• If a given function requires input from elsewhere
  (including input derived from another function),
  this can be simulated by sending dummy values to
  the function.
• Then, one can code stubs for other functions.
  A stuba function with an interface, but without
  a full implementation.

6
Stubs and drivers (cont.).

• A stub may contain a trace statement e.g.
  Function X entered OK. This can be used to
  test the logical structure of the program, to see
  if various pathways are followed correctly. For
  example one can check if the function is called
  if, and only if a certain condition is true.

7
Stubs and drivers (cont.).

• One can also develop any of the stubs by filling
  in the implementation, one function at a time,
  and testing it.
• See example STUBDRIV.CPP

8
2. Unit testing and integration testing.

• Unit testing testing each function separately as
  a function?
• Why?
• Analogy checking that all of the parts for a
  model airplane / Bionicle are sound.
• Unless each of the parts is sound, no chance that
  the whole will be.

9
Unit testing and integration testing (cont.).

• But unit testing is not enough.
• Why?
• Just because each part is sound, does not mean
  that the whole will be (fallacy of composition).
  Why?
• Compare all players passed their fitness test /
  all of these are trained actors.

10
Unit testing and integration testing (cont.).

• So, in addition to unit testing, need integration
  testing checks that all of the modules (1) are
  correctly coordinated
• (2) interface (communicate) correctly.
• Note that functions have pre-conditions (what
  should be true before the function is called) and
  postconditions.

11
Unit testing and integration testing (cont.).

• The postconditions of an earlier function should
  be the preconditions of the next function.
  Analogy with soccer one player needs to make a
  pass which sets up the next player for his
  play.
• E.g. the preconditions of a calculation function
  are that all givens have been input and any
  values to calculate have been initialized (to
  zero or other initial value).

12
3. Review for Test 2.

• As preparation for test 2
• 1. Find the errors in some badly designed
  function code.
• 2. Practice coding a function.
• 3. See the review sheet.
• An expanded version of the review sheet is posted
  on the CSC250 site.