CMPT 280 Intermediate Data Structures and Algorithms

1. CMPT 280Intermediate Data Structures and Algorithms Text: Data Structures and Software Development in an Object-Oriented Domain Java Edition by Jean-Paul Tremblay and Grant Cheston Prentice-Hall, 2003 (electronic versions of chapters to be provided) Reference: Big Java, 3rd edition, or Core Java Vol I, or other by Cay Horstmann Wiley & Sons, 2008

2. Tools that you are expected to know: • Java • Use it as an object-oriented language • Only use static methods and variables in special situations • Use of polymorphism • Marginal use of the Application Programming Interface (API) • GUI • Collection classes • Introduce and use dslib (data structures library developed at U of S) • Use preconditions • Postconditions and data invariants optional • Creation of executable jar files • Eclipse • Use in development of projects • Breakpoints and stepped execution for debugging • Refactoring (modifying) • JUnit testing • Perhaps not directly used • Encourage its use to test units as they are developed

3. Main topics: • Recall testing (1 lecture) • Timing analysis (1/2 week) • Abstract data types (1 lecture) • Lists and dictionaries of dslib (2 lectures) • Binary tree data structure (1 week) • Graph data structure and algorithms (11/2 weeks) • Specialized trees (1 week) • Sorting and recurrence relations (1/2 week) • File structures (1/2 week)

4. Testing Basics • Develop a test suite • A collection of tests • Good regression testing • Through • Easily rerun whenever a change is make • Data hard coded or read from a file • The test package handles all the setup necessary for each test • The expected results are hard coded or read from a file • The obtained results are compared against the expected results by the test package • Only problems are reported • If the execution is long, successful completion of stages might be reported • Expanded when new cases/situations are discovered that need to be tested

5. What is involved in an individual test? • Identification of the test case or situation • Determination of how to set up this case/situation • Input data • Initialization of the state • Determination of the expected result • Usually, the test must be simple enough to be able to determine the result manually • Coding of the test • Initialization of the state • The initialization is often the result of the previous test • Invoking the appropriate method or methods with the correct data • Checking that the actual result is the same as the expected result • Execution of the test • May need to test more than one method at a time • Need to use accessors/observers to check the results of modifiers and constructors Contrary to common Java style, as much as possible an individual method should be an accessor/observer/function, or a modifier/procedure - not a hybrid that returns something and changes something (the target object).

6. Techniques to identify test cases/situations • Black-box testing • Typical cases • Special cases • Including error handling, including precondition or postcondition failure • Different results obtainable • E.g., search finding the value or not • Boundaries • Often based on • the range of values for input • sizes • structure of a data structure • Use equivalence classes to reduce the number of test cases • White-box testing • Statement coverage • Branch coverage • Condition coverage • Path coverage In particular, consider ifs, switches, loops, and recursion. Often not possible to test all possible paths, so consider different cases (both true and false branch of an if), boundary cases (skip a loop, do it once, do it twice, max number of times), special paths, etc. • Gray-box testing

7. Problem: given a string and a string array, count the number of times the string occurs in the array. • Black-box testing:

8. Problem: given a string and a string array, count the number of times the string occurs in the array. • Black-box testing: • Number times it occurs: 0, 1, 2, many, all locations, all locations – 1 • Where the string appears in the array • First location, second location, mid locations, last location, second last location • Size of the array: 0, 1, 2, 3, large • Size of the string: length 0, 1, 2, many characters Note that string comparison is probably a built in operation so testing it is probably unnecessary • Error cases • String null • Array null Note that it is usually assumed that a test program compiles so that there is no need to test cases that don’t compile. e.g., something other than a string or array is passed in as a parameter

9. Problem: given a string and a string array, count the number of times the string occurs in the array. • White-box testing: publicstaticint count(String[ ] a, String s) { int count = 0; inti = 0; while (i < a.length) { if (s.equals(a[i])) count = count + 1; i = i + 1; } return count; }

10. Outer loop: • Not done: array length 0 • Done once: array length 1 • Done twice: array length 2 • Done many times: array length 5 • If condition • Never evaluates to true: string not in the array • Only true once: string occurs once • True twice: string occurs twice • Always true: string occurs in every location • Paths Note that different paths correspond to different locations where the string occurs. • String occurs in first location, second location, mid locations, last location, second last location Note that many test cases will be discovered by more than one technique. Note that the method should list and verify the precondition @precond a != null && s != null

11. Note the objective is to determine test situations/cases. • Test situation: • The identification of a situation (for which data can be obtained) to be coded and run to determine whether the algorithm obtains the correct result for this situation. For example, test with an array of size 1. For example, test with a string that is empty. • Often a lot of test situations will be obtained. • The objective is NOT one of the following: • Identification of tests that are needed inside the algorithm (to be tested). For example, a test of whether the array is null. For example, a test of whether the string occurs in location i of the array. For example, test if the string is empty. • Identification of tests to determine whether an particular execution of the algorithm yielded the correct answer. For example, test whether the value returned is 2 or not. For example, test whether the array was changed. • When testing a method, assume that all methods invoked from the method are correct unless recursion is involved.