CS1101X Programming Methodology Testing and debugging Testing and debugging are important activities in software development.

CS1101X Programming Methodology Programming Errors Compilation errors Syntax error (example: missing a semi-colon). Semantic error. (For example, applying modulus % on floating-point value for certain programming languages. In Java ,is it fine? Yes!) Easiest type of errors to fix. Runtime errors Occur at runtime. Java’s exception mechanism can catch such errors. Logic errors Program runs but produces incorrect result. Hard to characterize, hence hardest to fix. Programming errors are also known as bugs Origin: a moth in the Mark I computer.

CS1101X Programming Methodology Testing and Debugging Testing To determine if a code contains errors. Debugging To locate the error and fix it. Testing Yes Error? Debug

Testing vs. verification CS1101X Programming Methodology Testing vs. verification Testing A process of running a program on a set of test cases and comparing the actual results with the expected results. Verification A formal or informal reasoning that a program works for all possible inputs.

Black-box and White-box Testing CS1101X Programming Methodology Black-box and White-box Testing Black-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 design specification rather than the code Black-box testing is also known as functional testing White-box (or glass-box) testing indicates that we can “see” or examine the code as we develop test cases. white-box testing is also called structural testing. Complementary techniques

Testing paths through the specification CS1101X Programming Methodology Testing paths through the specification Black-box tests should test all paths through the specification. double sqrt( double x, double epsilon) { // requirement: x>=0 && .00001 < epsilon < .001 // result: x-epsilon <= sqrt*sqrt <= x+epsilon ... } To test all paths X = 0 and .00001 < epsilon < .001 X > 0 and .00001 < epsilon < .001 6

CS1101X Programming Methodology Path Testing White-box tests should be path complete. Design test data to check all paths Example if (x != 3) { y = 5; } else { z = z - x; }\ if (z > 1) { z = z / x; z = 0; } if (x != 3) y = 5 z = z - x if (z > 1) z = z / x z = 0 A C B D <x=0, z=1> Paths A, D <x=0, z=3> Paths A, C. <x=3, z=3> Paths B, C. <x=3, z=1> Paths B, D.

Path testing for loops while (x>0) { do something; x--; } The number of iterations is not known. It’s impossible to test all possible number of iterations. Test cases should include 0, 1, 2 iterations

Path-completeness doesn’t guarantee no errors int max (int x, int y, int z) { return x; } In the above program, there is only one path. Test case (3, 1, 2) works for the only path. Obviously, the program doesn’t work for a lot of inputs.

CS1101X Programming Methodology Testing Boundaries It is important to test the boundary conditions. Example final int CALENDAR_START = 1583; // validate input  if ((year < CALENDAR_START) || (month < 1) || (month > 12)) { System.output.println("Bad request: " + year + " " + month); } Suggests the following boundary tests Input Year Input Month 1582 2 1583 13 1 12

The testing phases Component/unit testing Testing of individual program components Usually the responsibility of the component developer Tests are derived from the developer’s experience Integration testing Testing of groups of components integrated to create a system or sub-system The responsibility of an independent testing team Tests are based on a system specification

Component being tested Tools for testing Test driver A driver simulates the part of a program that calls the component being tested. A program that automatically tests components. Stubs A stub is a program simulates part of a program called by the component being tested. stub Component being tested driver stub

Debugging Once errors are identified: it is necessary identify the precise location of the errors and to fix them.

CS1101X Programming Methodology Brute-force method Print statements Easy to add Provide information: Which methods have been called The value of parameters The order in which methods have been called The values of local variables and fields at strategic points Disadvantages Not practical to add print statements in every method Too many print statements lead to information overload Removal of print statements tedious

Turning Debugging Info On/Off CS1101X Programming Methodology Turning Debugging Info On/Off public static int sum(int a, int b) { int left = 0; int right = data.length - 1; if (debugging) { System.out.println("sum called with a = " + a + " b = " + b); } int total = a + b; System.out.println("total = " + total); return total; Use an extra boolean variable to turn on/off debugging info.

CS1101X Programming Methodology Debugger Using the debugger Stepping Breakpoint Inspecting variables

JDB Type “run” to execute the program Compile your source file with -g option Produce debugging information For example javac –g rsdimu.java To run jdb Type “jdb” to load an executable jdb <class name> Type “run” to execute the program Type “quit” to exit jdb

To attach JDB to a running JVM Start the JVM with the following options: java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=<port> <class> The JVM starts up, but suspends execution before it starts the Java application. In a separate session, you can attach the debugger to the JVM: jdb -attach <port> The debugger will attach to the JVM, and you can now issue a range of commands to examine and control the Java application; for example, type run to allow the Java application to start.

Breakpoint Make your program stops whenever a certain point in the program is reached For example Make a breakpoint in line 3 stop at DebugDemo:3 Program stops before execute line 3 Allow you to examine code, variables, etc. public class DebugDemo { public static void main() { System.out.println("A"); int x = 1; System.out.println("x="+x); } 1 2 3 4 5 6 7

Breakpoint Add breakpoint stop at MyClass:<line num> stop in java.lang.String.length stop in MyClass.<method name> Delete breakpoint clear (clear all breakpoints) clear <breakpoint> e.g. clear MyClasss:22 Line break point Method break point

Step Stepping into the current line. Execute the current line, then stop and return to JDB If the current line contains a call to a method, the execution traverses to the first line in the called method.

Next Stepping over the current line. Similar to step, but treat function call as one source line.

cont Resume continuous execution of the program until either one of the followings Next breakpoint End of program

print Print Display the value of an expression print expression print MyClass.myStaticField print i + j + k print myObj.myMethod() (if myMethod returns a non-null) print new java.lang.String("Hello").length() Dump Display all the content of an object dump <object>

Homework Design path-complete test cases for each of the programs below. (a) int max(int x, int y, int z) { if (x>y) if (x>z) return x; else return z; if (y>z) return y; else return z; } (b) while(x>0) { if (y<0) {do something and then break;} do something; x--; y--;