Testing
and
Debugging
Session 9
LBSC 790 / INFM 718B
Building the Human-Computer Interface
Agenda
•	Questions

•	Testing

•	Debugging

•	Show and tell
Types of Errors
•	Syntax errors
–	Detected at compile time

•	Run time exceptions
–	Cause system-detected failures at run time

•	Logic errors
–	Cause unanticipated behavior (detected by you!)

•	Design errors
–	Fail to meet the need (detected by stakeholders)
Types of “Testing”
•	Design walkthrough
–	Does the design meet the requirements

•	Code walkthrough
–	Does the code implement the requirements?

•	Functional testing
–	Does the code do what you intended?

•	Usability testing
–	Does it do what the user needs done?
Planning Functional Testing
•	You can’t test every possibility
–	So you need a strategy
•	Several approaches
–	Object-level vs. system-level
–	Black box vs. white box
–	Ad-hoc vs. systematic
–	Broad vs. deep
•	Choose a mix that produces high confidence
Planning Usability Testing
•	Define one or more scenarios
–	Based on the requirements (not your design!)
–	Focus only on implemented functions
•	Provide enough training to get started
–	Usually with a little supervised practice
•	Banish pride of authorship
–	Best to put programmers behind one-way glass!
•	Record what you see
–	Notes, audiotape, videotape, key capture
Best Practices
•	Design before you build

•	Focus your learning

•	Program defensively

•	Limit complexity

•	Debug syntax from the top down
Focus Your Learning 
•	Find examples that work
–	Tutorials, articles, examples

•	Cut them down to focus on what you need
–	Easiest to learn with throwaway programs

•	Once it works, include it in your program
–	If it fails, you have a working example to look at
Defensive Programming
•	Use set and get methods
–	Limits unexpected “side effects”

•	Check entry conditions in each method
–	Flags things as soon as they go wrong

•	Write modular code
–	Lots of method calls means lots of checks
Limiting Complexity
•	Single errors are usually easy to fix
–	So avoid introducing multiple errors

•	Start with something that works
–	Start with an existing program if possible
–	If starting from scratch, start small

•	Add one new feature
–	Preferably isolated in its own method
Debugging Compiler Errors
•	The first error message is meaningful
–	But subsequent ones may not be!
–	Fix one thing, then recompile
•	The line number is where it was detected
–	It may have been caused much earlier
•	Understand the cause of “warnings”
–	They may give a clue about later errors
•	If all else fails, comment out large code regions
–	If it compiles, the error is in the commented part
Run Time Exceptions
•	Occur when you try to do the impossible
–	Use a null variable, divide by zero, …

•	The cause is almost never where the error is
–	Why is the variable null?

•	Exceptions often indicate a logic error
–	Find why it happened, not just a quick fix!
Debugging Run-Time Exceptions
•	Run the program to get a stack trace
–	Throwable().printStackTrace
–	Read it from the outside in
•	Set a breakpoint just before the error
–	Examine variables at the breakpoint
•	Work backwards to find the cause
–	Use logic as far as it takes you
•	If necessary, set a breakpoint much earlier
–	Then “single step” until you see the problem
Logic Errors
•	Evidenced by inappropriate behavior
•	Can’t be automatically detected
–	“Inappropriate” is subjective

•	Sometimes very hard to detect
–	Sometimes dependent on user behavior
–	Sometimes (apparently) random

•	Cause can be hard to pin down
Debugging Logic Errors
•	First, look where the bad data was created

•	If that fails, print variables at key locations
–	Use if (DEBUG) {System.out.println(…);}
–	Or set “watch” on appropriate variables

•	Examine output for unexpected patterns

•	Once found, proceed as for run time errors
–	Set DEBUG to false to clean up the output
Debugging Tools
•	Useful for finding run time and logic errors
•	Three strategies
–	Add code to print out what is happening
•	System.out.println(“x= “ + x);
–	Use the Eclipse debugger
•	Debug menu
–	Use the Java 2 SDK debugger
•	jdb yourClassName
Debugging with Eclipse
•	Open the “debug perspective”
–	Window->Open Perspective->Debug

•	Set breakpoints
–	Double-click in left margin to set (circle appears)
–	Right-click on circle to set condition/hit count

•	Start the debugger
–	Run->Debug
Stepping With Eclipse
•	Step into
–	If a method is invoked, the first line of the method
–	It at a return, the line that called this method
–	Otherwise, the next line in the present method

•	Step over
–	If at a return, the line that called this method
–	The next line in the present method

•	Step return
–	The line that called this method
Starting JDB
•	Compile
–	javac –g (and not –O)
•	Start the debugger
–	jdb YourClassName
•	Set breakpoints
–	stop in Class.method (or stop at Class.NNN)
•	Run the program
–	run
Working with JDB
•	list: print the code near here
•	Print: print any expression (using variables)
•	locals: list all local variables
•	step: do one Java statement (up to a ;)
•	next: like step, but does not stop in methods
•	step up: continue to the end of this method
•	cont: continue from a breakpoint
•	help
•	exit