Introduction

This assignment is based on recent testing-related topics that we have seen in class.

In completing this assignment, you will learn how to:

• ●  Develop a comprehensive set of test cases based on a piece of code’s implementation

• ●  Measure the amount of code coverage achieved by a test set

• ●  Use defensive programming to improve the reliability of a piece of code

• ●  Write test cases that demonstrate the correctness of your implementation of defensive programming

• ●  Write test cases for a piece of code that has dependencies on other pieces of code using mock objects

  You will need Java 9 or later for this assignment, as well as JUnit 4.
  
  

  Part 1: Code Coverage-Based Testing

  In this part of the assignment, you are asked to conduct white-box testing on three methods that are based on and/or use the Apache Commons Math library, a set of lightweight, self-contained mathematics and statistics components.

  
  Getting Started

  You can access the code that you will test in this GitHub repo; you may fork it or just copy the code. Note that the repo contains three classes for the methods that you will test, as well as corresponding JUnit test methods.

  The repo also contains a .jar file for the Apache Commons Math library. Be sure you include this in your buildpath/compilepath when compiling and running the tests.
  
  

  Testing Activities

  In this part of the assignment, you need to write JUnit tests for these three methods: ● MyFractions.addSub
  ● MyPrime.nextPrime
  ● MySorter.sortInPlace

  Note that all three of these are in the code we provided and not in the Apache Commons Math library!
  
  

  Your goal is to create a set of unit tests that achieves 100% coverage of reachable statements for each of the methods listed above.

  Be sure to follow the conventions discussed in class regarding the naming of test classes/methods and how test methods are separated, specifically that each test case should be in a separate test method with a meaningful name.

  Note that MyPrime.nextPrime calls MyPrime.isPrime; you do not need to write tests for isPrime or attempt to achieve any coverage level in it.

  Also, note that MySorter.sortInPlace uses the Java varargs feature, and that if you want to compare arrays (which you do!), you can use the assertArrayEquals method from JUnit. Note that you need to provide a “delta” value for comparing the doubles in the array, as described in the documentation.

  Regarding the expected behavior of MySorter.sortInPlace, let's say x is {5, 3, 4} and one of the arrays in yList is {7, 8, 9}. When x is sorted:

  • ●  the second value (3) becomes the first value

  • ●  the last value (4) becomes the second value

  • ●  the first value (5) becomes the last value
    
    

    So the same reordering should be applied to each array in yList:

  • ●  the second value becomes the first value, which means that 8 goes first

  • ●  the last value becomes the second value, which means that 9 goes second

  • ●  the first value becomes the last value, which means that 7 goes last
    
    

    So the array in yList should now be {8, 9, 7}

    For MyFractions.addSub, the expectation is that:

  • ●  The ordering of the Fractions that are the arguments to the method indicate the order of the operands

  • ●  For the third argument, true means “add” and false means “subtract”

    So addSub(f1, f2, true) should return a new Fraction with the value f1+f2, and addSub(f1, f2, false) should return a new Fraction with the value f1-f2.

    When writing your tests, it is not enough just to have test cases that call each method with various inputs so that the different statements are covered: your tests must be sound and should use assertions to check that the actual output/behavior matches the expected output/behavior.

    Also, do not assume that the code is correct and that whatever it produces is what it should produce; use the specification in the code and above to determine the correct expected output/behavior. For determining prime numbers, you may want to use a website such as http://www.isprimenumber.com when writing your tests.
    
    

    On a related note, please do not post public questions in Ed about faults you may have found in the code. It is up to you to determine how to write sound test cases, some of which should fail if there are bugs in the code.

    Aside from writing new test cases, you should not change the implementation of any classes that we provided, and do not need to fix any bugs that you find. If you think a change is necessary, please speak with the instructor.
    
    

    Measuring Coverage

    We strongly recommend using an IDE such as Eclipse, IntelliJ, or VS Code for this assignment so that you can use the IDE to measure the coverage that your tests are achieving.

    For most IDEs, after you run your JUnit tests you should be able to open the code in the code editor window and you'll see covered statements in green and uncovered statements in red. Yellow statements are decision points for which branches have only been partially covered; you can consider these as “covered” for our purposes.