CS428/9: Software Engineering II

1. CS428/9: Software Engineering II Darko Marinov (slides from Ralph Johnson)

2. Administrative info • HW 2 due today, grade by Thu, Mar 1 • ACP revision 2 due on Thursday, Mar 1 • If you failed revision 1, meet with Tracy • Mar 1: Guest lecture on testing video games • Travis Tholen from Volition/THQ onQuality Assurance: General Software Testing • Mar 6: Midterm (in 213 Greg Hall and here, more info will be on Wiki) 428-12

3. Testing: Covered • Previously • Classic Testing Mistakes (by Brian Marick) • Kinds of testing (Hamlet & Maybee, ch. 6 & 19) • Black- and white-box techniques (H & M, ch. 20 & 21) • JUnit • The Impossibility of Complete Testing (by Cem Kaner) • Testing non-functional properties, OO, acceptance, system; test doubles • Today: Assertions and debugging 428-12

4. Debugging • Purpose of testing is to find failure • Failure: symptom - situation that gives wrong result • Produces bug reports, tests that fail • Purpose of debugging is to find and correct the fault • Fault: cause - mistake in the code • Produces changes to the code 428-12

5. Debugging • Tracing • Backtracking • Cause elimination 428-12

6. Tracing • Watch execution of program • Determine when it goes wrong • Print statements • Single stepping • Trace package • Breakpoints • Assertions / watchpoints 428-12

7. Backtracking • Determine a failure • Find fault by backing up to first failure • Repeatedly run program with new print statements • What could have caused this? Put in print statements to test each possibility. • Remove unneeded print statements 428-12

8. Backtracking • Works well with a regression testing tool • Reverse execution • Research • Record each change to variables • Back up execution by undoing changes 428-12

9. Cause elimination • What could cause this bug? • List all possibilities • Check each one: • By examining program • By performing experiments (tracing) • Requires knowledge of system and the errors that people make 428-12

10. Debugging expertise • Good debuggers know the model of the system • In their head • Can imagine how the system executes • Can perform mental experiments • Know their limits • Naming • Debugger: person or machine? • Tester: person of machine? 428-12

11. Debugging expertise • Good debuggers know the kinds of errors people make • C, C++: null pointer and other pointer errors • C, C++: losing memory, using memory twice • Not closing a file • Not initializing an object correctly • Sending message to wrong object 428-12

12. Error catalog • Testing and debugging depend on knowing common errors • Other people make the same kinds of mistakes that you do • So, learn the kinds of mistakes people make 428-12

13. Assertions Statements about a program’s execution that are either true or false. • Variable is an integer between 1 and 10 • Variable is not null • v1 < v2 428-12

14. Many uses of assertions • Formal specification • Contract-based development (Eiffel, Bertrand Meyer) • Low-level SE technique 428-12

15. gcd(a,b: INTEGER); INTEGER is -- Greatest common divisor of a and b require a > 0; b > 0 local x,y: INTEGER do from x := a; y:= b until x = y loop if x>y then x := x-y else y:= y-x end end; Result := x end

16. Assertions in Java • New Java statement in version 1.4 • assert exp1; • assert exp1: exp2; • If exp1 is false, throw an exception and give it exp2 as an argument • http://java.sun.com/j2se/1.4/docs/guide/lang/assert.html 428-12

17. An assertion in Java void gcd(int a,b) { assert a >0 && b>0; … } 428-12

18. An assertion in C void gcd(int a,b) { assert(a>0 && b>0); … } assert is a macro 428-12

19. Assertions • Some functions only work under certain conditions • Precondition: assertion that must be true before a function is executed in order for it to work • Function does NOT need to check it! • Postcondition: assertion that is true after a function 428-12

20. Assertions • Invariant is an assertion that is always true • Class invariant - a precondition and a postcondition of every method in the class • Loop invariant - an assertion that is true before the loop, after the loop, and every time through the loop 428-12

21. Assertions as programming tool • Execute assertions during testing and debugging • Do not execute assertions in production code 428-12

22. Assertions as programming tool • Write preconditions for procedures • Don’t write postconditions? • Can write unit tests • Write assertions • To match original specifications • For places that errors occur • Where you need them during debugging 428-12

23. Oracle • A test oracle is something that can tell you the right answer to a test. • Specifications that are clear, but slow • Check binary search by doing linear search • Inverse is easy to compute • x == Math.sqrt(x) * Math.sqrt(x) • A smart person 428-12

24. Difference between oracle and test • Test:test1in123() {assert(binSearch(new int[]{1,2,3}, 1) == true);} • Oracle:test1in123() {assert(binSearch(new int[]{1,2,3}, 1) == linSearch(new int[]{1,2,3}, 1));} 428-12

25. Random tests • Automate tests by • generate problems randomly, • use oracle to get answer • run test • Good for exploratory test, but not regression tests 428-12

26. Summary • Finding bugs is only half the battle • Write assertions incrementally • Write tests incrementally • Write code incrementally 428-12

27. Next time Testing video games 428-12