Unit Testing to Find Bugs

Mistakes in software are affectionately referred to as bugs. (The term did not originate with programmers, although it appears that programmers are responsible for the use of the word feature to mean "a bug that that has been documented".)

The purpose of testing is to reveal bugs. When we find bugs, we are happy! We are happy because we love to fix them, and we are especially happy when we can find them before shipping the product to the customer. (Or before submitting the product on Canvas, as the case may be.)

There may yet be other reasons that bugs make programmers happy...

In this exercise, you will write a set of JUnit test cases for a class called Balloon that models a simple toy balloon. See the javadoc for the Balloon class here. There are 5 versions of this class for you to try your tests on. Your task is to write a comprehensive set of unit test cases that enables you to identify what is wrong in the buggy versions, without seeing the source code. (This is sometimes called "black-box" style testing, since we can't see inside the implementation.)

The class files for all 5 versions of Balloon are in a jar file balloons.jar which you'll need to download and import into your lab6 project. This is just like importing a specchecker:

  1. Right-click on the lab4 project, select Import --> General --> File System, and click Next.
  2. Click Browse (From Directory) and find the directory where you downloaded balloons.jar.
  3. Check the box next to balloons.jar and click Finish.
  4. Now balloons.jar should appear under your lab4 project in the Package Explorer. Right-click on it and select Build Path --> Add to Build Path.

Then you can create a test class BalloonTests similar to BasketballExample test. Add an import statement: 

import balloon.Balloon;

All versions of the class are named Balloon, but they are in different packages. The correct implementation is balloon.Balloon, and the other four are in packages named balloon1 through balloon4. We suggest that when you start writing your tests, you validate them on the correct version. When you think you have a pretty good set of test cases, you can try the other versions just by changing the import statement, for example, to 

import balloon1.Balloon;
Then when you run the test, you'll be testing the version of Balloon from the balloon1 package (which should have some bugs). No other changes are needed in your test class. You can do the same to try the other versions of Balloon by changing the import statement.

Checkpoint 2

Write a set of unit test cases for Balloon. Each test case should focus on checking one simple fact about the behavior of the class. For example you might start by making a list of statements such as 
A newly constructed Balloon should have radius zero.
A newly constructed Balloon should not be popped.
After calling blow(5) on a Balloon with maximum radius 10, the radius should be 5.
Study the javadoc and write down some more facts that you might want to verify. Each of these facts becomes a test case. Write enough test cases that you would be comfortable spending your own hard-earned money on one of these Balloon objects, confident that it will work correctly.

For the correct version of Balloon, all your tests should pass. For the remaining versions of Balloon, your tests should enable you to to make a reasonable guess as to what the problem is in each of these classes.

  1. Show your tests to the TA.
  2. Demonstrate that they all pass for the correct version of Balloon.
  3. Demonstrate that at least one test case fails for each of the buggy versions
  4. Explain your conclusions about what is wrong in each of the buggy versions.