CS 161 Lab #9

Goals:

Directions:

1. Download the ClockTestingLab project and extract its contents, then start BlueJ and open the project. Take a look at the code in the two classes to remind yourself what's there and how it works.
2. Before you can use BlueJ's "recording" facilities to help build tests, you'll need to turn on the testing features: Use the View menu and make sure the "Show Team and Test Controls" item is checked. If all goes well, the project window should now have a "Run Tests" button below the "Compile" button (see above).
3. Since the ClockDisplay class builds off of the NumberDisplay class, it makes sense to test NumberDisplay first. (If NumberDisplay isn't working properly, then we wouldn't expect ClockDisplay to work either.) Create a testing class by right-clicking on NumberDisplay and selecting "Create Test Class" off of the menu that pops up. You should end up with a green class icon NumberDisplay. You can double-click on the new class to see what's there. BlueJ created a framework for our testing code, but it doesn't contain any actual tests yet.
4. Look at the source code for NumberDisplay for a moment, and think about how you'd test each of the methods. (Do it. I'll wait.) Before creating any JUnit test methods, let's manually test the constructor the "old fashioned" way: We'd expect that when a NumberDisplay object is created, its value is set to zero. Test this by right-clicking on NumberDisplay to create an instance of the class, then right-clicking on the NumberDisplay object and calling its getValue() method. It ought to return 0.
5. Now let's repeat that simple test, but build it into a JUnit test method. This time, instead of right-clicking on NumberDisplay, right-click on NumberDisplayTest (the green box behind NumberDisplay) and select "Create Test Method...". When prompted for a name, use constructor_InitiallyZero. (We're testing the constructor, and ensuring that the value is initially zero, and the name will remind us of that.) The red "recording light" should be on, which means BlueJ will watch everything you do from this point onward, whether it's in the codepad or pointing-and-clicking, and build it in to the test.

   Go ahead and repeat the test process: Create a NumberDisplay object, then call getValue on it. This time around, the resulting box looks a little different. BlueJ says the method has returned a zero, but it wants to know if it should always expect a zero there (and complain if it's not). Make sure the "Assert that" box is checked, enter a 0 in the box, then click Close. That's the end of this test, so click the "End" button under the recording indicator. Now if you look in the NumberDisplayTest class you'll see the new method at the bottom of the code. After compiling, you can right-click on the NumberDisplayTest class and "Test All" to run the new test, or click the "Run Tests" button on the left edge of the project window.

   
6. One test down, a bunch more to go... Let's continue writing tests, keeping them short and simple. For each of the tests below, follow the same steps as before: Right-click and "Create Test Method...", point-and-click your way through a test, then stop the recording. If you make a mistake while recording, you can either stop the recording and delete the botched test code, or keep going and then edit the automatically created code to fix the mistake. Create the following test methods:
   • constructor_InitialDisplay:
     Verifies that getDisplayValue returns "00" on a newly constructed NumberDisplay.
   • increment_InitialIncrement:
     Increments a newly constructed NumberDisplay once, then uses getValue() to verify that it had the desired impact.
   • increment_MultipleIncrements:
     Increments a NumberDisplay a handful of times, then uses getValue() to verify that they had the desired impact.
   • increment_Wraps:
     Increments a NumberDisplay enough times to cause it to wrap around, uses getValue() to verify that it goes back to zero, and that one more increment takes it to 1. (It's good to make sure that increments still work after wrapping around.)
   • setValue_LegalValues:
     Verify that setValue can set a NumberDisplay's value to legal values. You might try setting it to a value in the middle of the range, and also to the smallest and largest legal values, checking results with getValue() each time.
   • setValue_IllegalValues:
     Verify that if setValue is passed a value that's outside the legal range, it behaves as expected.
   • displayString_SingleDigit:
     Verify that the displayString method returns the expected string for single-digit NumberDisplay values.
   • displayString_DoubleDigit:
     Verify that the displayString method returns the expected string for double-digit NumberDisplay values.

   Make sure all of these tests run successfully before proceeding.

7. Whew! That was a lot of tests. Now that we know that NumberDisplay is working properly, let's write some tests for ClockDisplay. Right-click on ClockDisplay to create a test class, then right-click on the new test class to add the following tests:
   • constructor_InitialTime:
     Use getTime to verify that the time is "00:00" on a ClockDisplay constructed using the default (no argument) constructor.
   • setTime_SingleDigits:
     Verifies that setTime works on time values consisting of single digits (e.g. 05:07).
   • setTime_DoubleDigits:
     Verifies that setTime works on time values consisting of single digits (e.g. 15:47).
   • constructor_SpecifiedTimes:
     Test the second constructor to make sure it initializes a ClockDisplay correctly when passed legal values for hour and minute. (You might consider testing several possible legal values.)
   • timeTick_minutesOnly:
     Makes sure that timeTick() behaves as expected when doing increments that only affect the minutes (no wraparound). Do two or three increments, checking values after each.
   • timeTick_minutesAndHours:
     Makes sure that timeTick() behaves as expected when doing increments that make the minutes wrap around and increment hours (but in cases where hours won't wrap). Do two or three increments, checking values after each to make sure that hours only increments once.
   • timeTick_bothRollOver:
     Test the case where a timeTick() increment causes both the hours and the minutes to wrap around. (Set the time to 23:59, verify that the set worked, then do several increments, checking the time after each.)
     
8. Now let's make some changes to the original code that introduce bugs, and see if our tests can find them. Try the following, one at a time, running all of the unit tests after each change. If none of your tests catch the bug you've introduced, think about why, and how you'd adjust your tests to get better coverage. Undo each bug before trying another:
   • Change the NumberDisplay constructor so the time is initially set to 1 instead of 0.
   • In getDisplayValue(), change value < 10 to value <= 10. Then try value < 9 too.
   • Make changes to the boolean expression in setValue(). In ((replacementValue >= 0) && (replacementValue < limit)), try using an or (||) rather than and (&&). Try using > vs >= or <= vs <.
   • Mess with the increment() method so that it wraps back to 1 instead of 0, or the value gets too large before wrapping around.
   • Find some similar ways to break methods in ClockDisplay and see if your tests catch the bugs.

Extras

• Have your neighbor add a bug to your code somewhere while you're not looking. Run the unit tests and see if you can predict what the problem is without looking at the code.
• Use this as an opportunity to get more practice with the debugger — either to find a bug introduced by a neighbor, or to observe the operation of one or more of the ClockDisplay or NumberDisplay methods.
• Add new methods to ClockDisplay or NumberDisplay and then add tests to cover the new methods. For example, add an equals method to NumberDisplay that takes another NumberDisplay and returns true if the two are the same (have the same value and wrap-around limit). Then think about how to test equals via unit tests.
• Look at other code you've written recently — including the current assignment — and think about test cases that would be appropriate.