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 pass  Don'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 failing unexpectedly

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 driven_development