Program Correctness and Efficiency

1. Program Correctness and Efficiency Chapter 8

2. Chapter Objectives • To understand the different testing strategies and when and how they are performed • To learn how to write special methods to test other methods and classes • To become familiar with debugging techniques and debugger programs • To be introduced to the process of program verification and the use of assertions and loop invariants • To understand the meaning of big-O notation and how it is used to analyze an algorithm’s efficiency Azzam Mourad

3. Program Defects and “Bugs” • A program may be efficient, but is worthless if it produces a wrong answer • Defects often appear in software after it is delivered • Testing can never demonstrate the complete absence of defects • In some situations it is very difficult to test a software product completely in the environment in which it is used • Debugging: removing defects Azzam Mourad

4. Syntax Errors • Syntax errors are mistakes in the grammar of a language • The Java compiler detects syntax errors during compilation and requires you to correct them before successfully compiling the program • Some common syntax errors include: • Omitting or misplacing braces • Performing an incorrect type of operation on a primitive type value • Invoking an instance method not defined • Not declaring a variable before using it • Providing multiple declarations of a variable Azzam Mourad

5. Run-time Errors or Exceptions • Run-time errors • Occur during program execution • Occur when the JVM detects an operation that it knows to be incorrect • Cause the JVM to throw an exception • Examples of run-time errors include • Division by zero • Array index out of bounds • Number format and Input mismatch error • Null pointer exceptions Azzam Mourad

6. Logic Errors • A logic error occurs when the programmer or analyst • Made a mistake in the design of a class or method • Implemented an algorithm incorrectly • Most logic errors do not cause syntax or run-time errors and are thus difficult to find • Sometimes found through testing • Sometimes found during real-world operation of the program Azzam Mourad

7. Testing Programs • There is no guarantee that a program that is syntax and run-time error free will also be void of logic errors • The “best” situation is a logic error that occurs in a part of the program that always executes; otherwise, it may be difficult to find the error • The worst kind of logic error is one that occurs in an obscure part of the code (infrequently executed) Azzam Mourad

8. Structured Walkthroughs • Most logic errors arise during the design phase and are the result of an incorrect algorithm • Logic errors may also result from typographical errors that do not cause syntax or run-time errors • One form of testing is hand-tracing the algorithm before implementing • Structured walkthrough: designer must explain the algorithm to other team members and simulate its execution with other team members looking on Azzam Mourad

9. Levels and Types of Testing • Testing: exercising a program under controlled conditions and verifying the results • Purpose is to detect program defects after all syntax errors have been removed and the program compiles • No amount of testing can guarantee the absence of defects in sufficiently complex programs • Unit testing: checking the smallest testable piece of the software (a method or class) • Integration testing: testing the interactions among units Azzam Mourad

10. Levels and Types of Testing (continued) • System testing: testing the program in context • Acceptance testing: system testing designed to show that the program meets its functional requirements • Black-box testing: tests the item based on its interfaces and functional requirements • White-box testing: tests the software with the knowledge of its internal structure • Exp 2.11 p.88 Azzam Mourad

11. Preparations for Testing • A test plan should be developed early in the design phase • Aspects of a test plan include deciding how the software will be tested, when the tests will occur, who will do the testing, and what test data will be used • If the test plan is developed early, testing can take place concurrently with the design and coding • A good programmer practices defensive programming and includes code to detect unexpected or invalid data • Exp p.89 (end of the page) Azzam Mourad

12. Testing Tips for Program Systems • Most of the time, you will test program systems that contain collections of classes, each with several methods • If a method implements an interface, its specification should document input parameters and expected results • Carefully document each method parameter and class attribute using comments as you write the code • Leave a trace of execution by displaying the method name as you enter it • Display values of all input parameters upon entry to a method Azzam Mourad

13. Testing Tips for Program Systems (continued) • Display the values of any class attributes that are accessed by this method • Display the values of all method outputs after returning from a method • Plan for testing as you write each module rather than after the fact • Exp p. 90 (if testing…) Azzam Mourad

14. Developing the Test Data • Test data should be specified during the analysis and design phases for the different levels of testing: unit, integration, and system • In black-box testing, we are concerned with the relationship between the unit inputs and outputs • There should be test data to check for all expected inputs as well as unanticipated data • In white-box testing, we are concerned with exercising alternative paths through the code • Test data should ensure that all if statement conditions will evaluate to both true and false Azzam Mourad

15. Testing Boundary Conditions • When hand-tracing through an algorithm or performing white-box testing, you must exercise all paths • Check special cases called boundary conditions • Exp p. 91, 92 and 93 (and listing 2.5) Azzam Mourad

16. Who does Testing? • Normally testing is done by • The programmer • Other members of the software team who did not code the module being tested • Final users of the software product • Do not rely on programmers for testing as they are often blind to their own oversights • Companies also have quality assurance organizations that verify that the testing process is performed correctly • In extreme programming, programmers work in pairs where one writes the code and the other writes the tests Azzam Mourad

17. Stubs • It may be difficult to test a method or class that interacts with other methods or classes • The replacement of a method that has not yet been implemented or tested is called a stub • A stub has the same header as the method it replaces, but its body only displays a message indicating that the stub was called • Exp. p. 94 (Listing 2.12) Azzam Mourad

18. Drivers • A driver program declares any necessary object instances and variables, assigns values to any of the method’s inputs, calls the method, and displays the values of any outputs returned by the method • You can put a main method in a class to serve as the test driver for that class’s methods • Exp of driver is the main of listing 2.5 • Exp of testing a class p. 95 and 96 Azzam Mourad

19. Using a Test Framework • A test framework is a software product that facilitates writing test cases, organizing the test cases into test suites, running the test suites, and reporting the results • A test framework often used for Java products is JUnit, an open-source product that can be used in a stand-alone mode and is available from junit.org Azzam Mourad

20. Debugging a Program • Debugging is the major activity performed by programmers during the testing phase • Testing determines if there is an error, debugging determines the cause of it • Debugging is like detective work • Inspect carefully the information displayed by your program • Insert additional diagnostic output statements in the method to determine more information • Exp. (insert print statements…) Azzam Mourad

21. Using a Debugger • Debuggers often are included with IDEs • A debugger can execute your program incrementally rather than all at once • Single-step execution executes in increments as small as one program statement • Breakpoints are used to traverse large portions of code before stopping • The actual mechanics of using a debugger depend on the IDE that you are using Azzam Mourad

22. Using a Debugger (continued) Azzam Mourad

23. Reasoning about Programs: Assertions and Loop Invariants • Assertions: logical statements about a program that are claimed to be true; generally written as a comment • Preconditions and postconditions are assertions • A loop invariant is an assertion • Helps prove that a loop meets it specification • True before loop begins, at the beginning of each repetition of the loop body, and just after loop exit Azzam Mourad

24. Efficiency of Algorithms • Difficult to get a precise measure of the performance of an algorithm or program • Can characterize a program by how the execution time or memory requirements increase as a function of increasing input size • Big-O notation • A simple way to determine the big-O of an algorithm or program is to look at the loops and to see whether the loops are nested Azzam Mourad

25. Efficiency of Algorithms (continued) • Consider: • First time through outer loop, inner loop is executed n-1 times; next time n-2, and the last time once. • So we have • T(n) = 3(n – 1) + 3(n – 2) + … + 3 or • T(n) = 3(n – 1 + n – 2 + … + 1) Azzam Mourad

26. Efficiency of Algorithms (continued) • We can reduce the expression in parentheses to: • n x (n – 1) 2 • So, T(n) = 1.5n2 – 1.5n • This polynomial is zero when n is 1. For values greater than 1, 1.5n2 is always greater than 1.5n2 – 1.5n • Therefore, we can use 1 for n0 and 1.5 for c to conclude that T(n) is O(n2) • Exp. p. 110, 111 (Listings 2.15, 2.16, 2.17 and 2.18) • Comparing performance p. 116, 117 (tables) • Exp. Of exponential and factorial (cryptography algo.) Azzam Mourad

27. Efficiency of Algorithms (continued) Azzam Mourad

28. Chapter Review • Three kinds of defects can occur in programs • Syntax errors • Run-time errors • Logic errors • All exceptions in the Exception class hierarchy are derived from a common superclass called Throwable • The default behavior for exceptions is for the JVM to catch them by printing an error message and a call stack trace and then terminating the program Azzam Mourad

29. Chapter Review (continued) • Two categories of exceptions: checked and unchecked • A method that can throw a checked exception must either catch it or declare that it is thrown • “throw” statement throws an unchecked exception • Program testing is done at several levels starting with the smallest testable piece of a program called a unit • Integration testing: once units are individually tested, they can then be tested together • System testing: once the whole program is put together, it is tested as a whole Azzam Mourad

30. Chapter Review (continued) • Acceptance programming involves testing in an operational manner demonstrating its functionality • Black-box testing tests the item based on its functional requirements without knowledge of its internal structure • White-box testing tests the item using knowledge of its internal structure • Test drivers and stubs are tools used in testing • Test drivers exercise a method or class • Stubs stand in for called methods • Big-O notation determines the efficiency of a program Azzam Mourad