Testing vs.

Debugging
Testing finds problems
Unit test Integration test System test

Debugging finds and fixes causes of problems

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
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.
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.

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).
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.
CS1: chr, jeh, & tmh@cs.rit.edu

Debugging
Fix one problem at a time. Retest. This is called regression testing. Be sure you didnt correct a problem in one place but create a new problem somewhere else. When all problems are fixed, rerun a full suite of tests.

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.

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 wont know if your work is correct!
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 Entries shall have exactly three fields.

Number of inputs - one valid, two invalid classes 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. 3.

Write test cases to cover each valid equivalence. Combine these into as few tests as possible. Write test cases to cover each invalid equivalence class. Specify a separate test for each of these.
Prof. John Noll, Santa Clara Univ. CS1: chr, jeh, & tmh@cs.rit.edu