Objectives:

• Practice writing JUnit Test cases
• Practice brainstorming "black box" test cases

Problem Statement

You will be given code with bugs in it. Find failing test cases for each broken class and method. Specifically, you will be finding bugs in two methods:

int compareTo(Date other)

Compares two Date objects. Returns a negative integer if this Date comes before the Other Date; a positive integer if this comes after other; and, returns 0 if they are equal. For example given

• d1 = new Date(3, 4, 2005)
• d2 = new Date(4, 5, 2005)

then, d1.compareTo(d2) should return a negative integer, d2.compareTo(d1) should return a positive integer, and d1.compareTo(d1) should return 0.

int daysSince(Date other)

Returns the number of days that have elapsed between other and this. For example, using the Dates above, d2.daysSince(d1) should return 32, d1.daysSince(d2) should return -32; and, d2.daysSince(d2) should return 0.

Workflow

1. Begin by following this link and cloning the resulting git repository. The key files include:
   • lib/brokenDates.jar: This class contains several classes named BrokenDate1a, BrokenDate1b, etc. Each class has a bug. Don't open or modify this file.
   • test/BrokenDateTest.java: This will be your test class. I have provided a few sample tests to help you get started. The sample shows the name of each class and tells which method in that class is broken.
   • lib/junit-platform-console-standalone-1.6.2.jar: This contains the JUnit library. Your IDE probably provides it; but, I provided it in case you need it.
2. Open and edit test/BrokenDateTest.java For each broken class, add test cases until you find a failing test case. The failing test case indicates you have found the bug.
3. Note: The src folder will be empty. The emphasis of this lab is black box tests, so you won't get to see the source code.
4. When you have found all the bugs:
   • Commit / push your code so I can grade it.
   • Include your test cases in your tests for Project 1.

Rules

• You may work alone, or in teams of two.
• Attempting to modify, decompile, or otherwise gain access to the contents of brokenDates.jar (or any other file not intended for student use) is a violation of the Academic Honesty Policy.

Hints

1. Make sure the tests you write are supposed to pass. For example, the test below is not what I'm looking for because is should fail: March 4th comes before March 5th, so the compareTo method is expected to return a negative integer. Your goal for this lab is to find pairs of dates that don't produce the expected output.

     // DON'T do this.  This is an example of what I'm NOT looking for!
     @Test
     public void thisIsABadExample() {
       BrokenDate1a d1 = new BrokenDate1a(3, 4, 2005);
       BrokenDate1a d2 = new BrokenDate1a(3, 5, 2005);
   
       // This is a bad test because d1.compareTo(d2), if implemented correctly, should return a negative number.
       // You only want to find failing test cases that should not be failing.
       assertTrue(d1.compareTo(d2) > 0);
     }
     

2. Here is one way of taking an organized approach to finding bugs in compareTo. Notice each date has three components: month, day, and year. The rules of date comparison require you to look at pairs of years, then pairs of months, then pairs of days. Within each pair, there are three choices: greater than, less than, and equal to. Three pairs with three choices gives you a total of 3^3 = 27 test cases. If you work through those methodically, you will find a failing test case for the first three broken date classes.
3. The fourth case is tricky: This broken compareTo method attempts to count the number of days since 1 January 1753; but, counts wrong because it assumes all years have 365 days. Think of a case where failing to account for leap years will give a wrong answer.

Submitting your Lab

This assignment is due at the end of the lab period.

To submit your project:

1. Commit/push with "[Grade me]" in the commit message.

Quick Git Reference

Cloning

To clone a repo (i.e., download it to begin using it):

1. Go to your repos main GitHub web page.
2. Click the green button labeled "Clone or Download"
3. Make sure the box says "Clone with SSH"
4. Copy the URL to the clipboard. (The URL should begin with "git@github.com:")
5. From the command line, run git clone the_url_you_copied

Committing / Pushing

To commit changes and push them to your repo:

1. From the root of your repo, run git add ..
2. Then run git commit -m "your_message_here". The main purpose of the message is so you can look back on the commits and know what additional work was done for each commit. I also use commit messages to know when you are ready for me to look at your work.
3. Finally, run git push.

Pulling

If changes were made to your repository from another location, be sure to run git pull before doing additional work. There are several ways external changes can happen. For example,

• You may be working on two different machines (e.g, a desktop and a laptop). To switch from the desktop to the laptop, you would push the changes on the desktop , then pull those changes onto the laptop.
• I may make changes to your code, either when providing feedback, or in response to a request for help.

Updated Saturday, 15 May 2021, 7:16 PM