Now we're going to take care of the exceptions we need to write a unit test and expect to remove to
throw an exception if there's nothing in there.
So here I can write a unit test that expect an illegal state exception, test expected.
Is equal to a legal state exception, not class.
The unit test is called Invalid Remove State.
And first, I'm going to remove both items from the array list.
And I'm going to try to call a remove a third time.
If I run the test now, it fails, it's expecting the test to throw in a legal state exception, but
it isn't.
So now we're going to make the test pass by throwing an illegal STD exception from remove, if the card
is empty, then throw an illegal state exception.
And pass on a message.
We were on the test.
And perfect.
Can this could be made simpler, not the code, but we can make the unit test more concise.
I don't like how the cart class doesn't have a method we can just use to clear the shopping cart calling
remove so many times is kind of awkward.
Someone should avoid method name to clear that clears the area list.
This item is the clear, and that is all.
Now, back in the unit test, we can just clear the shopping cart.
And everything still works as it should.
All right, the final test we got to write is one that expects Check-Out to throw an exception if there's
nothing in there.
So here I can read another unit test that expects an illegal STD exception.
The unit test is called invalid check out state.
First, I'll clear the shopping cart.
Then I'll try to call check out.
If I run the test now, it fails, it's expecting the test to throw an legal state exception, but it
isn't.
So we got to make the test pass by throwing an illegal fit exception from check out if the card is empty.
Then throw in a legal state exception.
Pass a message.
Run the test and perfect.
Now, what I'm going to do is run every single test.
They all passed, which means the code in Kadirgamar doesn't have any books.
And just have a look at how clean and elegant the code is, when you write tests, before you write
code, you're being forced to write code that is easy to test.
And such code tends to be more polished.
Each method performs one task.
Each method is modular, is immune to bugs and easy to understand.
This is why I love test driven development writing tests before writing code.