A test case is composed of two things: an input that you would expect your program to handle, and the expected output for that input.

Test cases help prove that your program behaves as it should. It is best if you write your test cases before you run them through your program, although some test case outputs (like those for most labs you have done so far) can easily be verified as correct after the fact. It may not be so easy to eyeball if the answer is correct later on.

You should invent test cases that will put pressure on all different parts of your program. Questions you might ask yourself about your program as you think of test cases:

• Does it handle bad input? (What if a monkey was pounding on the keyboard?)
• Does it handle upper/lower case?
• Does it have rounding errors?
• Does it test the “border cases”?
• Do my test cases explore all of the if/else blocks of my code? All the methods? Is every line of code used by at least one test case?

The overall question is:

• Will my program behave properly under any situation?

You cannot try all possible test cases, but you can pick a few important ones that illustrate the possible places that your code could fail. When working on labs, create enough test cases to illustrate that your program handles each of the lab requirements (and then some).