Testing

1. Testing Chapter 23 IB103 Week 12 (part 3)

2. Verify that a complex (any) program works correctly, that the program meets specifications • The chapter reviews different approaches – to check (verification) and notes deficiencies

3. Approaches to verification • Black box (functional) • White box (structural) • Reviews (walkthroughs) • Stepping through code with debugger • Formal methods

4. In Java the classes are a natural size piece to work with • A class at a time (to check/debug) • After every class has been tested (unit testing) the complete system is tested (integration or system testing) • Example specifications • “ input to the program is a series of numbers via a text field, terminated by a negative number. Display the sum.”

5. After review: • Are the numbers integer or floating point? • What is the range and precision? • Is the terminating negative number to be included in the sum?

6. Clarification to the specifications: • Integer numbers to be used • Range from 0 to 10000 • Button “End of Data” now terminates (so no need to worry about a terminating negative number)

7. Tests: • Black box – we assume no knowledge of the programs inner workings – we only consider in/output (functional) • Select representative data • Key in 8 12 [End of Data] button • Key in just [End of Data] button • Key in 8 0 12 [End of Data] button what was expected in each trial? • Note discrepancies • Use equivalence partitions, identify common features

8. White box: • Make use of knowledge of how program works, it’s structure • Test all possible paths (with simple data)

9. Inspections and walkthroughs • Study source code listings • Try to detect bugs (before the compiler does) • Have another person (pair of eyes) check your program – sometimes we cannot see forest for the trees. Others can see our errors and we can bring a fresh viewpoint looking at their program

10. To inspect: • Need specifications • Text of source code • Some checks to be made • Variables initialized? • Loops initialized and terminated? • Methods invoked and are passed correct parameters? • Desk check (play computer) line by line • Does the method achieve its desired purpose?

11. Other considerations • Are variable names meaningful? • Indentation consistent? • Logic clear and correct? • Step through the code a line at a time check the value held by variables (use debugger if possible) • Formal verification – using mathematics • Does program meet the specifications

12. Z and VDM languages that check specifications (not commonly used) • 1. Write program and verify it meets specifications • 2. Derive program from specifications be means of transformations (favored more common approach)

13. Unit testing and integration (system) testing • May use all approaches or combination • (black, white – boxes, inspection and debugger, step through) • Create a test bed (check each method, display output independent of program) Then if method runs put it into the system Incremental development Write small piece of code: key it in, compile,run debug add to program the tested piece, Repeat until program is complete