Description
In this lab you will be creating a directional speedster class, providing some functionality for it,
and creating JUnit test cases for that class.
Instructions
Start off by creating a new project with a package called cpsc2150.Speedster. Then add the
provided IDirectionalSpeedster interface (provided for you) to your cpsc2150.Speedster Package. This
Interface. will help us track the time, distance and speed of our travel. However, unlike the example
given in class, we must now consider the direction of travel. We can do that by imagining an x,y
coordinate plane. If we start at the origin (0,0) we can define movement in any direction by looking at
the change in x and the change in y. Those changes can be positive or negative, to allow us to move in
any direction. If we have moved from point (x1, y1) to point (x2, y2) then our distance = sqrt((x2 – x1)^2
+ (y2 – y1)^2).
Our IDirectionalSpeedster interface needs to keep track of the total distance travelled, the total
time of travel, the net distance travelled, the net velocity travelled, and the average velocity travelled.
What’s the difference between total distance and net distance? Imagine that we start at (0,0) and move
4 places to the right, putting us in position (4, 0). Then we move 2 spaces to the left to position (2, 0).
Our total distance travelled was 6, but our net distance travelled was 2, since at the end of our travel we
were only 2 spaces away from where we started. The difference is the same when we compare average
velocity to net velocity. When we calculate average velocity, we look at the total distance travelled
divided by the total time, and for net velocity we look at the net distance travelled divided by the total
time.
Next you should provide a class called DirectionalSpeedster that implements the provided
interface. There are many ways that this class could be represented in our private data. Feel free to use
whichever makes the most sense to you. The contracts in the interface give you this flexibility by
enforcing rules in the constraints and not just in the post conditions. If you can implement a method in
the interface as a default method, feel free to do so. Otherwise no other changes should be made to the
interface. Make sure to include comments, correspondences and invariants in your class.
Remember, you will need to provide a constructor for your class as well.
Constructor: DirectionalSpeedster()
This constructor takes in no arguments and sets all values to 0, including time.
DirectionalSpeedsterTest class
Use the instructions from last week’s lab to set up your test folder in IntelliJ and create a class
called DirectionalSpeedserTest.java. You will create your JUnit test cases in this class. Remember to set
up your build configuration to run JUnit test cases (instructions in Lab 7).
We will make several test cases for this class. Due to our class having private data, and limited
public functionality, we may need to have more than one function call in each test case. That’s OK, and
is often necessary, but we still want to limit each function in our JUnit test class to be one test case. For
instance, in order to see if addTravel was successful, we need to check to see if the current X position
and Current Y position have changed, so we will need to call getCurXPos and getCurYPos. We’ll just have
to remember that if the test case fails, there could be an issue with any of those functions and we would
need to check them all for potential faults. It may be helpful to separate our test case into two functions
that both use the same input, but one checks if the total distance is correct, and one checks if the total
time is correct. This would limit the places in code that our fault could be if only one of the test cases
fails. You don’t have to do that for this assignment, but it may be helpful if you are struggling to find the
cause of the failure.
For each test case, we should still only call the function we are testing once, even if we will need
to call other functions to see if the test case was successful. The only exception to this is the addTravel
method. If we have a test case that involves travel having occurred in the past, we will need to call
addTravel more than once to set up our test case. But we will only call our assert statements after the
last addTravel call.
Even though we will discuss Path testing in class before most of you have this lab, you do not
need to use that methods for identifying test cases for this assignment.
Make sure to follow our best practices for JUnit such as naming our functions appropriately.
Remember that best practices for JUnit and best practices for code are different. You are allowed to use
magic numbers in JUnit to hard code our inputs and expected outputs.
Testing the Constructor
You will need to test the constructor of the DirectionalSpeedster class. The constructor doesn’t
take in any arguments, so we really only have one test case. However, we do need to check to make
sure that the distance, time and current position on the grid are correct. You could separate these into
different test cases with the same input if you want.
Testing addTravel
Create 10 unique and interesting test cases for the addTravel function. Make sure your test
cases are not really testing the same concept, just with slightly different numbers. Consider different
challenging situations for the programmer. For each test case include a comment explaining why you
chose that test case. At this point I would only use the getCurXPos and getCurYPos functions to verify
that this function is working correctly. Remember, even though we may call addTravel more than once
to set up our test case, we should only call our assert statements after the last addTravel call.
Testing getTotalDistance()
Create five unique and interesting test cases for the getTotalDistance function. Make sure your
test cases are not really testing the same concept, just with slightly different numbers. Consider
different challenging situations for the programmer. For each test case include a comment explaining
why you chose that test case. You will need to call addTravel multiple times to have an interesting test
case, so if your test case fails make sure that addTravel is working as intended as well. Remember, since
we are testing getTotalDistance, we should only call getTotalDistance one time.
Testing getNetDistance()
Create five unique and interesting test cases for the getNetDistance function. Make sure your
test cases are not really testing the same concept, just with slightly different numbers. Consider
different challenging situations for the programmer. For each test case include a comment explaining
why you chose that test case. You will need to call addTravel multiple times to have an interesting test
case, so if your test case fails make sure that addTravel is working as intended as well. Remember, since
we are testing getNetDistance, we should only call getNetDistance one time.
Testing getAverageSpeed()
Create five unique and interesting test cases for the getAverageVelocity function. Make sure
your test cases are not really testing the same concept, just with slightly different numbers. Consider
different challenging situations for the programmer. For each test case include a comment explaining
why you chose that test case. You will need to call addTravel multiple times to have an interesting test
case, so if your test case fails make sure that addTravel is working as intended as well. Remember, since
we are testing getAverageVelocity, we should only call getAverageVelocity one time.
Testing getNetSpeed()
Create five unique and interesting test cases for the getNetVelocity function. Make sure your
test cases are not really testing the same concept, just with slightly different numbers. Consider
different challenging situations for the programmer. For each test case include a comment explaining
why you chose that test case. You will need to call addTravel multiple times to have an interesting test
case, so if your test case fails make sure that addTravel is working as intended as well. Remember, since
we are testing getNetVelocity, we should only call getNetVelocity one time.
Running your code on Unix
How to run JUnit code on unix was covered in the slides. Make sure your code will run in Unix.
You must create a makefile that will compile you code with the “make” command and run the JUnit test
cases with the “make test” command.
TIPS and additional Requirements
– In JUnit 4 assertEquals(double actual, double expected) has been replaced with
assertEquals(double actual, double expected, double epsilon). This handles the fact that we lose
precision with double values at very small decimal places. We could expect a function to return
2.0 and it actually would return 2.00000000000001, which would be marked as a failed test
case. We can use epsilon to define an acceptable error, so assertEquals will return true as long
as abs(actual – expected) < epsilon. You can define a constant value to use as epsilon
– It will be difficult to test our function calls individually, since we have private data. It is ok to
have more than one function call to properly test your code. Just be aware of that when you see
a failed test case. However, a test case should still only have one input set and one final
expected output, and should only call the tested function once (except for addTravel).
– Inputs that are interesting and unique for one function may be interesting and unique for
another function. It is ok to reuse inputs to test different functions as long as they are good test
cases for both functions.
– Don’t get caught up on the contracts we wrote for the Speedster class during lecture. Adding in
the directional functionality actually has a big impact on what is and is not allowed in the
contracts.
– Note that Speed, time, and velocity are all allowed to be zero with this interface. Someone can
call getAverageSpeed before adding travel, and should get a zero in return.
– Remember, our best practices are different for JUnit and for normal code. Make sure to follow
the appropriate best practices.
Groups
You may, but are not required to, work with a partner on this lab. Your partner must be in the
same lab section as you, not just the same lecture section. If you work with a partner, only one person
should submit the assignment. You should put the names of both partners in a comment at the top of
the file in order for both partners to get credit. This assignment may take more than just the lab time.
Make sure you are able to meet outside of class to work on the assignment before you decide to work
with someone else. Remember to actively collaborate and communicate with your partner. Trying to
just divide up the work evenly will be problematic.
Before Submitting
You need to make sure your code will run on Unix with the makefile you have provided. Make
sure your package directory is set up correctly. The TA should be able to unzip your code and enter the
commands “make” and “make test” to run your code.
Submitting your file
You will submit your files using handin in the lab section you are enrolled in. If you are
unfamiliar with handin, more information is available at https://handin.cs.clemson.edu/help/students/