Now that we've identified every test case, the second step is to start unit testing.
Your first task was to set up avoid method named set up.
Public void setup.
And we're going to give this method a before annotation.
When you annotate a method with before it's going to run, before each test in this method is where
you would initialize the variables that each test is going to depend on in this case, each test is
going to depend on us setting the store equal to a new object of the store class.
OK, now we can start, you know, testing, we're going to follow the order from requirements dot text.
The first test case tells us to check if the story contains a movie after it's been added.
So I'll create a unit test named the added test.
Public void movie added.
And checking if his store contains a movie depends on us adding the movie first, so we'll do that inside
the before method.
Stalked and movie will add a new movie.
And it's going to be The Shawshank Redemption.
Blu ray.
Nine point to.
We'll do the same thing here and The Godfather.
The store doesn't have an ad method, so we need to go to store Java.
Public void at movie.
And the before method implies that ad movie should receive an object of the movie class.
And here, I guess I'll just have to add a new copy of the movie Object Inside the Aerialists.
OK, now how do we make sure the odd movie method is working as it should?
Inside the movie and on unit test, we need to check if the story contains the movie object that was
added.
We're going to use a true.
To check if the store contains The Godfather.
We're going to assert the store contains the movie after adding its.
And now inside Staudt Java, we need to write code to make the test fail, I'll create a public boolean
method called Contains.
And the unit test implies that our method needs to receive a movie object.
And it's really nice that our unit test is basically telling us how to write our code, and here the
only thing we can do is return a boolean that checks if this movie contains the movie parameter.
OK, our test should fail.
Which is fine, because that's the first step to writing a unit test, so it says that it was expecting
true, but our unit test returns false.
And this is where you ask yourself, why is my test failing if you put a breakpoint here?
You can see that the store already contains two objects courtesy of our before method.
Well, step inside the function.
But remember, that contains uses the default equals method to compare movie objects, so it compares
the reference of each movie against the movie parameter.
The reference for passing in isn't equal to any of the references inside the array list.
So ultimately contains determines that the area list doesn't contain the object being passed in.
But if we create our own equals method for objects of the movie class and contains is going to use that
one instead.
So inside the movie class, we're going to customize the equals method.
The equals method needs to return a boolean and receives an object, what's the type of that object?
We don't know.
It can be any object.
But first, we're going to check if the object that we're comparing against is No.
Because if it happens to be null, then there's no way it equals the movie object that's calling this
method, otherwise it would have thrown a null pointer exception.
And assuming that the movie object, is it no, we need to check if it isn't of type movie.
And if the object isn't an instance of the movie class, we'll return false.
OK, so at this point, the object, is it no, it is an instance of movie, so we can typecast it to
type movie.
And finally, we need to check if the objects fields are equal to the current object that's calling
this method, we need to compare the name format, rating, selling price range, price and availability.
We need to check if its fields are equal to the current object that's calling this method.
And it passes.
Here you can visualize that the contains method is using your equals method to compare each movie in
the array list.
This points to the current movie that's calling equals, and here's our parameter.
The parameter is not no.
It is an instance of movie.
But their fields aren't equal.
So equals returns false for the first element.
And if you keep going.
The parameter is not no.
It is an instance of movie.
And their fields are equal, so equal returns, true.
And because equals returns true, contains returns true as well.
So our unit test passes.
All right, since the unit test passes, we can rest assured that our code doesn't have any bugs, but
can it be refactored?
No, because the code is as elegant as it's going to be.