| CPSC 225 | Intermediate Programming | Spring 2025 |
The purpose of this lab is to practice identifying test cases for code, and to introduce patterns for automating testing in order to facilitate regression testing, the practice of re-running tests to ensure that bug fixes are successful and that previously developed and tested code hasn't been broken by bug fixes, new features, or other changes.
Labs are due at the start of lab on the date listed. It is OK to hand in your files at the very beginning of lab, but you should not be spending part or all of a lab period finishing up the previous week's lab.
To be eligible for revise-and-resubmit, you must turn in something by the due date. Late work and extensions are generally not accepted/granted; see the posted late policy for more information.
You may work with a partner if you wish. Both partners must actively contribute to the solution! You only need one handin for the group — be sure to put both teammates' names in every file.
Otherwise you may get help but you may not use other resources (friends, neighbors, websites, ChatGPT, etc) to produce answers. See the posted policy on academic integrity for more information.
To hand in your work:
Make sure that your name is at the beginning of each file (use the @author tag in Java files) and that all your Java files have been auto-formatted.
Copy the entire lab2 project directory from your workspace ~/cs225/workspace to your handin directory in /classes/cs225/handin.
Check that everything got handed in correctly — navigate to your handin directory and make sure it contains a directory lab2 with your bug-report file and a subdirectory src containing your testers.
Your task in each part is to develop a suite of test cases to thoroughly test the code described, and to report on the bugs found. Keep in mind that the goal is to develop a complete test suite, not to only find the bugs present in the provided variants. To this end it is not required to report on bugs in more than variant 1 for each of the three parts...but pitting your tester against a wider variety of bugs can help you be more thorough with your test cases.
Variant 1 in each case has at least one bug. Other variants may have no bugs, but there's at most one correct implementation provided for each part.
Create a new Java project called lab2 in Eclipse.
In the Files application (not Eclipse!), create a folder lib inside your lab2 project folder and copy /classes/cs225/lab2/lab2.jar and /classes/cs225/lab2/lab2-variants.jar files into the lib folder.
In Eclipse, right-click on the lab2 project name in the Package Explorer and choose Refresh. You should now see the lib directory and the two jar files inside in the Package Explorer.
Right-click on lab2.jar and choose Build Path → Add to Build Path. You should see a "Referenced Libraries" section appear for the project in the Package Explorer. Repeat for the lab2-variants.jar file.
Import the three Java files from /classes/cs225/lab2 into your project. Make sure they end up in the src directory!
If all is well, there shouldn't be any compiler errors and you should be able to run the three testers. (RPSTester won't do anything yet.)
Based on the API description above, identify test cases for sort3. Keep in mind that you'll need to identify three things for each test case:
There's no starting state here because sort3 is a static method — no need to create objects.
Document the test cases you identify by implementing them as described in the next section.
SortTester.java contains a framework for implementing the test cases. The idea of the tester is to run all of the test cases and produce output that makes it easy to determine if each test passed or failed. Since sort3 produces output, we'll also print the expected output (the correct answer) to make it easy to compare. The runTestCase method does this — it takes parameters for the name of the test case (so the tester's output is easy to understand), the input provided to the thing being tested (the three values a, b, c), and the expected output and then calls sort3 and prints the actual and expected output for comparison.
main contains one call to runTestCase to demonstrate its use. Comment out that demo case and add similar calls for the test cases you've identified.
Run your suite of tests and identify the bugs (if any) by indicating which test cases fail. Create a text file called bug-report for your answers:
The lab2-variants.jar file contains three additional implementations of sort3 with different bugs (or perhaps no bugs at all). To try your tester with these variants, locate the line with Sort3Variant1.sort3 in runTestCase and change it to Sort3Variant2, Sort3Variant3, or Sort3Variant4. You do not need to report on bugs found or not found in these variants, but there's at most one correct implementation provided so if all of your tests pass for several variants, you're missing some test cases...
To get around the challenges of a 12-hour clock (does 5:15 mean 5:15 am or 5:15 pm?) and the many time zones around the world, Coordinated Universal Time (UTC), also known as Greenwich Mean Time (GMT) or Zulu time (Z), is used. This is a 24-hour clock based on a single time zone. Times are written in the form 0815Z, with the Z at the end indicating Zulu time.
It is still useful to express times in the local timezone, however. This reference gives the offsets from Zulu time (UTC) for the time zones in the US. In this exercise you'll only need to deal with the mainland US time zones (Eastern, Central, Mountain, Pacific, and both daylight savings and standard times).
Based on the API description above, identify test cases for convert. Keep in mind that you'll need to identify four things for each test case:
Document the test cases you identify by implementing them as described in the next section.
TimeTester.java contains a framework for implementing the test cases. This version of runTestCase is similar to the one for sort3 but since convert returns its result, we can also print "passed" or "failed" along with the result returned and the expected result to make it easy to see which tests failed.
main contains one call to runTestCase to demonstrate its use. Comment out that demo case and add similar calls for the test cases you've identified.
Run your suite of tests and identify the bugs (if any) by indicating which test cases fail. Add your answers to your bug-report file.
The lab2-variants.jar file contains four additional implementations of convert with different bugs (or perhaps no bugs at all). To try your tester with these variants, locate the line creating a new TimeVariant1 object in runTestCase and change it to TimeVariant2, TimeVariant3, TimeVariant4, or TimeVariant5. You do not need to report on bugs found or not found in these variants, but there's at most one correct implementation provided so if all of your tests pass for several variants, you're missing some test cases...
Rock Paper Scissors is a time-honored way of settling debates and making choices. The goal is a program which, given a series of plays from each player and a number of rounds to win, determines the outcome — the first player to the desired number of wins is the winner.
how many wins needed? 2 player 1, enter your moves [R/P/S]: RRPPSS player 2, enter your moves [R/P/S]: RPSRPS player 2 wins!
To facilitate testing, the program's functionality has been divided up into two key methods, one to determine the winner of a single round and one to determine the winner over a series of rounds.
Based on the API description above, identify test cases for both getRoundWinner and getGameWinner. One wrinkle is that these methods aren't independent — getGameWinner uses getRoundWinner for each round within the game. Identify test cases for getGameWinner assuming that getRoundWinner works — that is, focus just on what could go wrong with getGameWinner itself.
Keep in mind that you'll need to identify three things for each test case:
There's no starting state here because getRoundWinner and getGameWinner are static methods — no need to create objects.
Document the test cases you identify by implementing them as described in the next section.
RPSTester.java contains a framework for implementing the test cases...well, actually it just has an empty main program. First add runTestCaseRound and runTestCaseGame methods to run test cases for RPSVariant1.getRoundWinner and RPSVariant1.getGameWinner respectively. Follow the style from the previous exercises — will you want these to simply print the actual and expected results, or to also print "passed" or "failed"?
Implement your test cases using those methods.
Run your suite of tests and identify the bugs (if any) by indicating which test cases fail. Since getGameWinner uses getRoundWinner, only pay attention to the results of the getGameWinner tests if all of the getRoundWinner tests pass — that way you know the problem with getGameWinner is its fault and not the result of a problem with getRoundWinner. Add your answers to your bug-report file.
The lab2-variants.jar file contains four additional implementations of getRoundWinner and getGameWinner with different bugs (or perhaps no bugs at all). To try your tester with these variants, locate the lines with RPSVariant1 in your runTestCase methods and change them to RPSVariant2, RPSVariant3, RPSVariant4, or RPSVariant5. You do not need to report on bugs found or not found in these variants, but there's at most one correct implementation provided so if all of your tests pass for several variants, you're missing some test cases...