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

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

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 won’t know if your work is correct!

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.