Testingand

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