Testing and Debugging

Testing Fundamentals  Test as you develop Easier to find bugs early rather than later Prototyping helps identify problems early  Categories of bugs software crashes or data corruption failure to meet or satisfy the specification poor or unacceptable performance hard or difficult to use

Testing fundamentals  Impossible to test a program completely  Three distinct paths through the program  If the loop executes 20 times, there are 3 20 different sequences of executions

Reviews and inspections  Inspections Formal process of reviewing code First employed by IBM in 1976 Early work showed that design and review inspections remove 60 percent of the bugs in a product

Reviews and inspections  Roles of participants Moderator  Runs the inspection  Ensure that the process moves along  Referees the discussion  Ensures action items done Inspector  Someone other than author  Some interest in the code  Carefully review code before inspection meeting Author  Minor role  May answer questions about code

Reviews and inspections  Roles of participants Scribe  Record all errors detected  Keep list of action items

Reviews and inspections  Inspection process Planning  Code to review chosen  Moderator assigns task  Checklists created  Moderator assigns a presenter (usually one of the inspectors) Overview  Author describes high-level aspects of project that affected the design or code  Sometimes skipped (if all participants are knowledgeable)

Reviews and inspections  Inspection process Preparation  Working alone, each inspector reviews code noting problems or questions  Shouldn’t take more than a couple of hours Inspection meeting  Presenter walks through the code  Problems are discussed  Scribe records all errors and action items  Errors are not fixed at this time Inspection report  Moderator prepares a written report

Black-box and white-box testing  White-box testing indicates that we can “see” or examine the code as we develop test cases  Block-box testing indicates that we cannot examine the code as we devise test cases Seeing the code can bias the test cases we create Forces testers to use specification rather than the code  Complementary techniques

Black-box and white-box testing Test boundary conditions public static int binarySearch(char[] data, char key) { int left = 0; int right = data.length - 1; while (left <= right) { int mid = (left + right)/2; if (data[mid] == key) { return mid; } else if (data[mid] < key) { left = mid + 1; } else { right = mid - 1; } return data.length; }

Black-box and white-box testing Boundary conditions // validate input if ((year 12)) { System.output.println("Bad request: " + year + " " + month); return; }

Black-box and white-box testing  Suggests the following boundary tests Input YearInput Month

Black-box and white-box testing  Path coverage or path testing—create test cases that causes each edge of the program’s controlflow graph to be executed Example if (x != y) { y = 5; } else { z = z - z; } if (x > 1) { z = z / x; } else { z = 0; } if (x != 3) y = 5z = z - x if (x != 3) y = 5

Black-box and white-box testing  Testing tips Test early Use inspections Test boundaries Test exceptional conditions Make testing easily repeatable

Integration and system testing  Integration testing is done as modules or components are assembled. Attempts to ensure that pieces work together correctly Test interfaces between modules  System testing occurs when the whole system is put together

Debugging  Use the scientific method Gather data Develop a hypothesis Perform experiments Predict new facts Perform experiments Prove or disprove hypothesis

Debugging  Tips and techniques Simplify the problem Stabilize the error Locate the error Explain the bug to someone else Recognize common bugs  Oversubscripting  Dereferencing null Recompile everything Gather more information Pay attention to compiler warnings Fix bugs as you find them Take a break