A fraction is represented by the Fraction interface. This interface should contain the following methods:

A method to add two fraction objects: Fraction add$($Fraction other$).$

A method to add a fraction with another given as a numerator and denominator: Fraction add$($int numerator,int denominator$).$ This method should throw an IllegalArgumentException exception if the fraction provided to it is negative.

A method that returns the decimal value of a fraction, rounded to the given number of places: double getDecimalValue$($int places$).$

Create the above interface, and document its specifications as detailed above.

Design JUnit tests that verify these specifications for an implementation called SimpleFraction $.$

Implement the Fraction interface in a SimpleFraction class. Leave all the methods blank for now, but document them properly. The specifications for this implementation $($beyond what the interface specifies$)$ are:

This class can only represent a non$-$negative fraction. Any attempt to create a negative fraction through the constructor should throw an IllegalArgumentException $.$

This class should have a single public constructor that takes the numerator and denominator as integers as its only arguments. Note that these arguments can be individually negative, even as the constructor imposes the above constraint.

This class should also override the toString method, which returns a string of the form $"$n$/$d$".$ For example, a fraction created with numerator $2$ and $4$ should return $"2/4"$ through its toString method, whereas a fraction created with numerator $-4$ and denominator $-9$ should return $"4/9"$ through its toString method.

Note that wherever applicable, you may not assume that this is the only implementation of the Fraction interface.

The add methods should not simplify the result. The addition of $"1/2"$ and $"1/2"$ should be $"4/4"$ and not $"1/1"$

For each method to be implemented in the SimpleFraction class: design and write all JUnit tests to verify its specification, then complete the implementation and run the tests. Proceed in this "write tests $->$ implement method $->$ run tests" to complete the class.

The purpose of the constructor is to create the object as specified, or die trying $($i$.$e$.$ throw an exception$).$ The latter can be readily tested, but how to test the former? Since we cannot $($should not$)$ directly access fields from the test, one has to look to other $($simple$)$ methods to test this. But how do we know those methods are themselves correct? If these methods are short and simple $($e$.$g$.$ they do not compute anything, but rather directly report something about the object$)$ then it is improbable that they work incorrectly. It is a "leap of faith" in some ways, but it fulfills our objectives of testing everything we implement, while also not resorting to make fields accessible or write methods just to be able to test.

Fix the style, and submit on the submission server. To submit, select the src$/$ and test$/$ folders $($in Finder$/$Explorer$)$ and compress them. Submit this zip file to the server. When you view your submission, you should see src$/$ and test$/$ as the two top$-$level folders.

Look at and fix any style and test errors. You may submit multiple times.

The second add method does not really belong in the interface, although hopefully you found it useful. A consequence of putting it in the interface is that it is a public method in all its implementations.

Can you redesign your classes and interfaces such that this method is no longer public, but other methods still work as described? Whatever design you come up with, what are its limitations$?$

Implement this design and show to the course staff. Note that parsing the result of the toString method is one way, but there is a better design that is possible.

An alternative way is fuzzy testing, or random$-$sample testing. This type of testing is useful when a method can have a large number $($seemingly infinite$)$ of inputs that produce expected outputs. It works as follows:

Determine if it is possible to categorize the possible inputs $($e$.$g$.$ all positive numbers, all negative numbers, etc.$).$ This will depend on the specific problem at hand.

For each category, generate a large number of random inputs using a random number generator. Be sure to give a constant seed to the generator, so that one can run the test repeatedly and be assured of the same set of random inputs.

Write a test that repeatedly $($e$.$g$.$ using loops$)$ uses a random input and verifies expected output$($s$).$

How large should the sample size be $($i$.$e$.$ how many sets of random inputs should we try$)?$ Note that this testing probabilistic in nature: we are hoping that we test enough inputs so that the probability of any input producing the correct expected output is "high enough". A few thousand samples are usually a good default size to start with.

Test your add method using fuzzy testing. Now test the other methods similarly.