1
00:00:00,360 --> 00:00:04,260
Now we're going to take care of the exceptions we need to write a unit test and expect to remove to

2
00:00:04,260 --> 00:00:06,120
throw an exception if there's nothing in there.

3
00:00:06,630 --> 00:00:12,090
So here I can write a unit test that expect an illegal state exception, test expected.

4
00:00:14,560 --> 00:00:16,840
Is equal to a legal state exception, not class.

5
00:00:20,570 --> 00:00:23,300
The unit test is called Invalid Remove State.

6
00:00:29,110 --> 00:00:31,660
And first, I'm going to remove both items from the array list.

7
00:00:55,420 --> 00:00:57,430
And I'm going to try to call a remove a third time.

8
00:01:04,650 --> 00:01:09,810
If I run the test now, it fails, it's expecting the test to throw in a legal state exception, but

9
00:01:09,810 --> 00:01:10,440
it isn't.

10
00:01:17,960 --> 00:01:23,300
So now we're going to make the test pass by throwing an illegal STD exception from remove, if the card

11
00:01:23,300 --> 00:01:25,520
is empty, then throw an illegal state exception.

12
00:01:33,870 --> 00:01:35,250
And pass on a message.

13
00:01:39,990 --> 00:01:40,860
We were on the test.

14
00:01:46,210 --> 00:01:47,350
And perfect.

15
00:01:51,140 --> 00:01:55,670
Can this could be made simpler, not the code, but we can make the unit test more concise.

16
00:01:58,010 --> 00:02:03,500
I don't like how the cart class doesn't have a method we can just use to clear the shopping cart calling

17
00:02:03,500 --> 00:02:05,570
remove so many times is kind of awkward.

18
00:02:07,870 --> 00:02:11,200
Someone should avoid method name to clear that clears the area list.

19
00:02:18,470 --> 00:02:21,170
This item is the clear, and that is all.

20
00:02:24,120 --> 00:02:26,880
Now, back in the unit test, we can just clear the shopping cart.

21
00:02:33,210 --> 00:02:34,880
And everything still works as it should.

22
00:02:40,360 --> 00:02:45,400
All right, the final test we got to write is one that expects Check-Out to throw an exception if there's

23
00:02:45,400 --> 00:02:46,090
nothing in there.

24
00:02:46,720 --> 00:02:50,020
So here I can read another unit test that expects an illegal STD exception.

25
00:02:56,240 --> 00:02:59,240
The unit test is called invalid check out state.

26
00:03:10,200 --> 00:03:12,200
First, I'll clear the shopping cart.

27
00:03:14,590 --> 00:03:16,000
Then I'll try to call check out.

28
00:03:27,610 --> 00:03:33,010
If I run the test now, it fails, it's expecting the test to throw an legal state exception, but it

29
00:03:33,010 --> 00:03:33,460
isn't.

30
00:03:38,160 --> 00:03:44,460
So we got to make the test pass by throwing an illegal fit exception from check out if the card is empty.

31
00:03:48,330 --> 00:03:50,400
Then throw in a legal state exception.

32
00:03:52,220 --> 00:03:53,450
Pass a message.

33
00:04:03,120 --> 00:04:04,980
Run the test and perfect.

34
00:04:10,370 --> 00:04:12,320
Now, what I'm going to do is run every single test.

35
00:04:18,019 --> 00:04:21,950
They all passed, which means the code in Kadirgamar doesn't have any books.

36
00:04:24,600 --> 00:04:30,330
And just have a look at how clean and elegant the code is, when you write tests, before you write

37
00:04:30,330 --> 00:04:33,690
code, you're being forced to write code that is easy to test.

38
00:04:33,810 --> 00:04:36,450
And such code tends to be more polished.

39
00:04:36,720 --> 00:04:38,580
Each method performs one task.

40
00:04:38,580 --> 00:04:42,660
Each method is modular, is immune to bugs and easy to understand.

41
00:04:42,870 --> 00:04:48,270
This is why I love test driven development writing tests before writing code.