Test Driven Development

Derived from Dr. Fawcett’s notes

Phil Pratt-Szeliga

Fall 2009

Specifications and Testing

Requirements and Testing are intimately related Requirements define completely and unambiguously

what the software shall do Testing verifies that the software meets its

requirements specification Small projects have simple, informal

specifications Large projects need much more

Each subsystem has its own requirements document Each subsystem has a suite of tests to run at various

levels The whole system has a suite of tests to run at

several levels

Test Harness Lots of testing can be automatic

Simply run a command and an extensive suite of tests is run Each test has a well defined pass/fail criteria Test reports are produced that show how many tests pass and

fail. If a test fails the report should include why it failed What cannot be automatic (easily and quickly with

current technology) User interfaces (current research topic) Visualizations

The image processing required to automatically test something like a paint program, let alone a video game, CAD designer or data visualization is not easy

If there are many automatic tests it is cost effective to provide some infrastructure for testing

Test Driven Development

Attempts to invert the usual sequence of development

Sequence of TDD: Write a test driver Add a shell in the product code that the test exercises Add code to the shell to implement functionality Attempt to compile and run and achieve passed test Repeat adding code until test passes

Test harness is almost universally used with TDD

TDD Process

Here is an excerpt from “test-driven development”, David Astels, Prentice-Hall, 2003: You maintain an exhaustive suite of Programmer Tests. No code goes into production unless it has associated tests. You write the tests first. The tests determine what code you need to write.

The following slides provide excerpts and interpretations drawn from this book.

Programmer Tests

Unit tests are written to test that the code you have written works

Programmer tests define what it means for the implementation to work (under TDD)

TDD implies that you have an exhaustive set of tests This is because there is no code until there is a test

that requires it in order to pass There should be no code in the system that was

not written in response to a test The test suite, by definition, is exhaustive

TDD Continued

In TDD the development cycle is very short

Make sure the test fails before you make it passDon't add extra code

Can also be applied to improving and debugging legacy code

TDD Continued

A subtle difference in TDD is that it forces the programmers to think of the requirements first

Features that are not needed are not included Even adding just an else without requiring it to

pass a test is wrong in TDD This makes the test suite not complete Instead you must add another test first

TDD Debugging

People report that using the debugger is more rare in TDD

The unit tests eliminate debugging When used in conjunction with version

control systems you can go back to a known good when tests start failingunexpectedly

Object Oriented TDD

A Mock Object can be used to have testing and real versions of code

Mock Objects are simulated objects that mimic the behavior of real objects

For example: Network Interface Mock Object combined with

Client Mock Objects to test server

Drawbacks of TDD

Difficult to do unit tests of User Interfaces Database applications Applications requiring specific network config

Management support is crucial Without it they may say time is wasted on unit tests

Badly written tests become a maintenance problem

The unit tests and the code are written by the same person, usually Misunderstand requirements twice

Extreme Programming A process model in the family of Agile

Development Methods Steps

1. Plan a series of releases each with some nominal functionality

2. Each release begins with a mini-plan, conducted with the customer. It continues with requirements analysis and top-level design

3. TDD is used for all implementation, using programmer pairs

4. After a release is delivered, the delivered code is refactored to improve its maintainability and robustness, before beginning the next phase

Refactoring uses the test apparatus developed for TDD

Refactoring Driven by three code attributes

Duplication in the code The code or its intent is not clear The code “smells” – there is a subtle or not so subtle

indication that there is a problem with the code Commented code replaced with clearer code that needs no

comments to be understood or maintained Data class or structs are replaced with classes with member

functions Inappropriate intimacy. Methods are moved so that pieces of

code that need to know about one another are in the same module or class

Partition large classes and modules into smaller, more-maintainable parts

Remove overly dependent classes. (Large strong components). Perhaps define interfaces or rearrange functionality

References

http://en.wikipedia.org/wiki/Test-driven_development