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

2. 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.

3. 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

4. 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.

5. 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

6. 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 && < epsilon < .001
// result: x-epsilon <= sqrt*sqrt <= x+epsilon
... }
To test all paths
X = 0 and < epsilon < .001
X > 0 and < epsilon < .001 6

7. 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.

8. 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

9. 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.

10. 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

11. 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

12. 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

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

14. 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

15. 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.

16. CS1101X Programming Methodology
Debugger
Using the debugger
Stepping
Breakpoint
Inspecting variables

17. 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

18. 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.

19. 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

20. 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

21. 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.

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

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

24. 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>

25. 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--;