1. CS1: chr, jeh, & tmh@cs.rit.edu Testing vs. Debugging Testing finds problems –Unit test –Integration test –System test Debugging finds and fixes causes of problems

2. CS1: chr, jeh, & tmh@cs.rit.edu Testing Static testing –Inspection –Code review –Walk-through Unit testing –Black box – Functional testing –White box – Structural testing Regression testing

3. CS1: chr, jeh, & tmh@cs.rit.edu A Test Strategy When code is messy, testing is hard. Java helps us by giving us the ability to test one piece (class) at a time. –Modularity methods objects –Encapsulation Data is packed with the methods (behaviors) that act on it. Private data means there is no other way to mess around with it.

4. CS1: chr, jeh, & tmh@cs.rit.edu Test Strategies Bottom-up test. Examine the Javadoc for the simplier methods, or for methods that are not dependent on others.

5. CS1: chr, jeh, & tmh@cs.rit.edu Debugging Recreate the problem. Think about the cause - don't try ad hoc testing. Narrow it down. Use debug statements. Vary data to pattern failures. Create tests that rule out portions of code (narrow the search).

6. CS1: chr, jeh, & tmh@cs.rit.edu Common Problem Areas Static variables treated like instance variables or vice-versa. Local variables treated like instance variables or vice-versa. –Same argument and instance variable names (recall the this example?). Invoking the wrong constructor. Off-by-one errors in ifs and loops. Faulty Boolean expressions.

7. CS1: chr, jeh, & tmh@cs.rit.edu Debugging Fix one problem at a time. Retest. This is called regression testing. Be sure you didn’t correct a problem in one place but create a new problem somewhere else. When all problems are fixed, rerun a full suite of tests.

8. CS1: chr, jeh, & tmh@cs.rit.edu Unit Testing In object-oriented programming, the logical unit to test is the class. –Create an object. –Call methods in different orders and with different argument values. Methods that modify state are called mutators. –Frequently check the state of the object to see if it is correct. Methods that reveal state are called accessors.

9. CS1: chr, jeh, & tmh@cs.rit.edu Writing a test harness Write a main method that creates instances of your class (creates objects), and then invokes the methods. Did everything work? Invoke its methods. Here's a pattern. 1.Call one method that modifies the object's state. 2.Call all methods that report the object's state. 3.Repeat #1-2 many times, with a different choice for the first step each time. This sounds trivial, but it can actually be a lot of work. This is critical -- you must test or you won’t know if your work is correct!

10. Prof. John Noll, Santa Clara Univ. CS1: chr, jeh, & tmh@cs.rit.edu Divide the input into equivalence classes. 1.Identify equivalence classes for each input type. Each input in a class yields the same (equivalent) execution path. –Range - one valid, two invalid classes Year between 1902 and 2038 –Number of inputs - one valid, two invalid classes Entries shall have exactly three fields. –Set (enumeration) - one valid class (the set), one invalid class (the set complement) Weekdays (not weekend days) –“Must be” constraint - one valid class (input satisfying constraint), one invalid class (input not satisfying constraint) Start date must precede End date. –Sub-classes - an equivalence class should be divided into sub-classes if elements of a given EC are handled differently by the program Passwords with fewer than 8 characters must include numbers as well as letters 2.Write test cases to cover each valid equivalence. Combine these into as few tests as possible. 3.Write test cases to cover each invalid equivalence class. Specify a separate test for each of these.