1. Testing and Debugging Session 9 LBSC 790 / INFM 718B Building the Human-Computer Interface

2. Agenda Questions Testing Debugging Show and tell

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

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

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

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

7. Best Practices Design before you build Focus your learning Program defensively Limit complexity Debug syntax from the top down

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

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

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

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

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

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

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

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

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

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

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

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

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