Discussion 2 Solutions: Unit Test Coverage

Solutions

Exercise 2: Check your Understanding
Why do we need to make sure that the tests are sound before using buggy implementations to assess their coverage?
As described in the handout, we look for failing tests against buggy implementations to assess test coverage. When tests are sound, this works because the test failures will correspond to deviations from the specifications in the buggy implementation (which was caught by the tests). When tests are not sound, then the test failures cannot necessarily be attributed to detected bugs.
Exercise 3: Checking your copyRange() Coverage
To get some practice interpreting the Gradescope output from these coverage tests, upload your CopyRangeTest.java file to the "Discussion 2" assignment in Gradescope (note that you aren't being graded on the autograder output; the usual discussion grading will be used), and take a look at the autograder results. Call the TAs over if you have any trouble navigating through the Gradescope interface. The autograder includes 10 entries. The first entry checks that your unit tests compile. The second entry assesses their soundness against a correct copyRange() implementation. The remaining entries run your tests against eight buggy copyRange() implementations to assess their coverage. For the eight coverage tests:
  • If you see green output from the autograder, then your tests found the bug(s) in one of our implementations. Look through the output to diagnose the bug and describe it below.
  • If you see red output from the autograder, then the buggy code evaded your tests. Try adding additional unit tests to your suite to increase your coverage.
Buggy Implementation 1:
This implementation does not return false when the length parameter is 0.
Buggy Implementation 2:
This implementation can modify the dst array before returning false in the case of invalid arguments.
Buggy Implementation 3:
This implementation does not correctly handle the case where src and dst alias the same array and the end of the dst range overlaps with the start of the src range.
Buggy Implementation 4:
This implementation does not correctly handle the case where src and dst alias the same array and the end of the src range overlaps with the start of the dst range.
Buggy Implementation 5:
There is an off-by-one error in the code checking whether the copyRange() arguments are valid.
Buggy Implementation 6:
This implementation does not handle the dstStart parameter correctly when it is greater than 0.
Buggy Implementation 7:
This implementation does not handle the srcStart parameter correctly when it is greater than 0.
Buggy Implementation 8:
This implementation sometimes errantly modifies the contents of the src array.
Exercise 4: Implementing copyRange() - Time Permitting
If you were able to track down all of the bugs, you should now have a good unit test suite that you can use for test-driven development of the copyRange() method. Try running the unit tests that you have written. As a reminder, follow these instructions from our IntelliJ guide to run tests. You should find that all of the tests fail. This makes sense; the copyRange() method hasn't been written yet.

Complete the definition of the copyRange() method. Use the unit tests that you wrote to guide your development. Choose a missing behavior or mishandled scenario that was identified by a failing unit test, and update the method definition to address this. Now, more unit tests should pass. Repeat this process until your code passes all of your unit tests.

ArrayUtilities.java