1

Debugging and Testing Overview Defensive Programming

The goal is to prevent failures Debugging

The goal is to find cause of failures and fix it

Testing The goal is to discover failures The goal is to verify the requirements

2

Defensive Programming Anticipate potential problems and

design and code the system so that they are avoided or at least detected as early as possible.

Defensive design – avoid bugs Defensive coding – localize problems

3

Defensive Design Make your design simple Use

encapsulation (decoupling of classes) – any class should not depend on any other classes on the same level

Design with error in mind – ask a lot of “what if” questions

4

Design Review Show design to somebody else: peers,

management, outside consultants Present design, it makes more details

about the design explicit and can uncover many problems

Implicit assumptions are uncovered

5

Make assumptions explicit Define pre- and post-conditions –

– assumptions about input parameters and the state of the object when the method is invoked

– output parameters and state of the object upon return

Make them part of the documentation and code itself

6

Specifying pre/post-conditions Establish the bounds of the input parameters Specify the condition of the object before and

after the function execution Specify the changes, if any, to the input parameters Can be done formally (predicate logic) or

informally (in words) in documentation

7

Example Function Search(array[size], size, key) Precondition: array is not empty, it is of

size ‘size’ Postcondition: if key is in array,

Search() returns index of key, otherwise -1

8

Defensive Coding Be suspicious:

– Public methods should check that the values of incoming parameters are within the expected ranges

– Check that called methods return valid values – Check for error conditions returned by called

methods – Check intermediate values/data if it can be done

inexpensively

9

Defensive Coding Ensure that data is initialized to meaningful

values Do code reviews Use assertions – a means to implement pre

and postconditions in the code Use exceptions – define special classes for

exceptions, use them to return error conditions that should be handled non-locally

Declare methods to throw exceptions

10

Evolutionary Programming Compile your code often Test your code before you implement

everything Evolve your program by writing modules

and using stubs

11

Debugging Use a symbolic debugger (dbx on Unix) If a memory checking tool is available, learn

to use it to locate memory problems THINK Keep an error log Whenever you discover an error, check for

the same error in other parts of the program

12

Error log When was the error made? Who made the error? What was done incorrectly? How could the error have been

prevented? How was the error found? How could the error have been detected

earlier and with less work?

13

Error repair Fixes are not always correct Fixing one problem often causes

several other problems Fix the problem and the symptom

14

Testing Software testing is a critical element of

software quality assurance and represents the ultimate review of specification, design, and coding

Testing should be carried out throughout the life-cycle: – Static: code inspections, walkthroughs – Dynamic: module, integration, system testing

15

Software Testing Myths If we were really good programmers,

there would be no bugs to catch Testing implies an admission of failure Testing is a punishment for our errors All we need to do is:

– Concentrate – Use OO methods – Use a good programming language

16

Software Testing Reality Humans make mistakes, especially

when creating complex artifacts Even good programs have 1-3 bugs per

100 lines of code People who claim that they write bug-

free code probably haven’t programmed much

17

Goals of Testing Discover and prevent bugs, not show

that program works The act of designing tests is one of the

best bug preventers known Even tests are sometimes buggy The real goal of testing is to reduce the

risk of failure to an acceptable level

18

Test types – another view System Test

The program is treated as a black box System requirements are tested against the black box

Integration Test Different components are integrated together Verify that different components within the system

work fine Unit Test

Small units of the program are subjected to testing. Test each function

Typically done as you write code

19

100 % Bug Free Software ? NO. Complete testing is NOT possible

for non-trivial software both practically and theoretically

Assuming a program only has one input of 10 characters, it would require 2^80 tests, which at 1microsecond/test would take more than twice the current estimated age of the universe

20

Test coverage Statement coverage: each statement is

executed at least once Decision coverage: every branch is

taken at least once Test for invalid, unexpected conditions Test for boundary conditions Use varied tests

21

Regression testing Every time new code is introduced/bugs

are fixed, all old test cases should still produce the correct output

Every time a new test case uncovers a bug, add it to your suit of test cases