All language subtitles for 018 Shopping Cart – Part 2_en

Now that we've identified every test case, the second step is to start unit testing.

Your first task was to set up a method annotated with before public void setup.

And we're going to give this method of before annotation, remember that when you edited a method with

before, then it's going to run before each test and each test is going to depend on us setting the

cart equal to a new object of the cart class.

Now we can start unit testing, we'll follow the order from requirements dot text, the first test case

tells us to check if the store contains an item after it's been added.

So I'll create a unit test named item added test.

And here I need to research the story contains an item that was added and checking if a store contains

an item, depends on us adding the item first.

So we'll do that inside the before method carport add.

Will add a new item.

Pepsi won ninety nine.

And we'll add another item to the shopping cart cart that add new item, Krush, also 199.

All right, but the store doesn't have an ad method.

So we need to go to Kadirgamar public void add.

And the before method implies that ad should receive an object of the item class.

And here, I guess I'll just have to add a new copy of the item object inside the array list.

OK.

And now how do we make sure the aid method is working as it should inside the item added unit test?

We need to check if the cart contains the item object that was added.

So we're going to use a true.

To check if the cart contains the crushed object.

This test asserts the cart contains a certain item, and now inside Staudt Java, we need to write code

to make the test fail, something to create a public boolean method called contains.

And here, the unit test implies that our method needs to receive an item object.

Again, it's kind of nice that we're writing our code based on how we set up our tests.

And here the only thing we can do is return a boolean that checks if this items.

That contains the item parameter.

All right, our test should fail.

Which is fine, because that's the first step to writing a unit test and it says that it was expecting

true, but our unit test returns false.

So this is where you ask yourself, OK, why is the test failing?

If you put a breakpoint here.

You can see that the cart already contains two objects courtesy of our before method.

The objects are equal in terms of state, their fields are equal, but remember that contains uses the

default equals method to compare item objects.

So it compares the reference of each item against the item parameter.

The reference that we're passing in isn't equal to any of the references inside the array list.

So ultimately, Java determines that the aerialist doesn't contain the object being passed in.

But if we create our own equals method from just the item class then contains is going to use that one

instead.

So inside the item 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.

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 item object that's calling this

method, let's assume the object is it now then we need to check if it isn't of type item if the object

isn't an instance of the item class.

Then return false.

OK, so at this point, the object, is it no, it is an instance of item, so we can typecast it to

type item.

And finally, we got to check if the objects fields are equal to the current object that's calling this

method.

We're going to compare the name and price from the object that's calling this method to the one that's

being passed in as a parameter.

All right, let's run the test now.

And it passes.

Here you can visualize it, the contains method is using your equals method to compare your object against

each item in the aerialists.

This points to the current item that's called the equals.

And here is the parameter.

The parameter is not known.

It is an instance of item.

But the fields aren't equal, so equals returns, falls for the first element.

And if you keep going, the second time equals gets called.

This parameter is not known.

It is an instance of item.

And the fields are equal, so equals returns, true.

And because equal is return, true contains determines that the Israelis does contain that object and

it returns true as well and 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 I be refactored?

The answer is no.

The code is as elegant as it's going to be.

The second test case tells us the card should skip a duplicate item, so I'll create a unit test named

SIP's Duplicate.

And here I'll make an assertion using a certain false assert, false expects the value to be false.

And we're expecting the odd method to return false if we add a duplicate item.

So back in C�rdova.

We have to write code to make the test fail, so I'm going to return true.

Our test should fail, which is fine.

It says that it was expecting faults, but our unit test returns true, so back in Car Java, we got

to write code to make the test pass.

We'll say if items that contains the item being passed in.

Return false.

Otherwise, we'll return true and add that item to the aerialists.

OK, rerun the test and it passes so we can rest assured that our code doesn't have any bugs, but can

it be a refactored?

The answer is no.

The code is as elegant as it's going to be.