1
|
- Session 9
- LBSC 790 / INFM 718B
- Building the Human-Computer Interface
|
2
|
- Questions
- Testing
- Debugging
- Show and tell
|
3
|
- Syntax errors
- 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
|
- 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
|
- You can’t test every possibility
- 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
|
- 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
|
- Design before you build
- Focus your learning
- Program defensively
- Limit complexity
- Debug syntax from the top down
|
8
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- 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
|
- Useful for finding run time and logic errors
- Three strategies
- Add code to print out what is happening
- System.out.println(“x=3D “ + x);
- Use the Eclipse debugger
- Use the Java 2 SDK debugger
|
17
|
- 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
|
18
|
- 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
|
- Compile
- Start the debugger
- Set breakpoints
- stop in Class.method (or stop at Class.NNN)
- Run the program
|
20
|
- 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
|