1
00:00:00,410 --> 00:00:05,570
There are two parts to test driven development, the first step is to identify a meaningful test cases

2
00:00:05,870 --> 00:00:08,870
and from the requirements, we identified three test cases.

3
00:00:10,680 --> 00:00:13,800
The goal of part two is to write a unit test for each case.

4
00:00:17,100 --> 00:00:19,800
First criticalness name, check out West Java.

5
00:00:26,500 --> 00:00:32,200
We're going to write a unit test for each test case and to write a unit test to write the test annotation.

6
00:00:39,700 --> 00:00:44,110
The first unit test is going to check if the subtotal equal to the sum of each price.

7
00:00:46,590 --> 00:00:49,350
So I'm going to call my test, subtotal is valid.

8
00:01:01,050 --> 00:01:04,290
OK, here comes the interesting part, we're going to make an assertion.

9
00:01:07,140 --> 00:01:12,450
Assert equals means comparing the value that we're expecting with the value that gets produced.

10
00:01:15,660 --> 00:01:17,400
What is the value that we're expecting?

11
00:01:18,820 --> 00:01:20,230
Let me take out my calculator.

12
00:01:25,400 --> 00:01:26,930
I'm going to add all my numbers up.

13
00:01:30,520 --> 00:01:32,170
And we get nineteen point two.

14
00:01:34,810 --> 00:01:40,750
That's the expected value, the value that we're expecting nineteen point two must be equal to the actual

15
00:01:40,750 --> 00:01:44,320
value that gets produced from a function we're going to call.

16
00:01:48,750 --> 00:01:51,420
Let's say Maine gets subtotal.

17
00:01:53,860 --> 00:01:59,230
So at this tells us is now we have to create a function called get subtotal instead of main Java.

18
00:01:59,560 --> 00:02:01,150
Public static double.

19
00:02:05,550 --> 00:02:06,570
Get subtotal.

20
00:02:13,490 --> 00:02:15,410
And Freneau just returned in zero.

21
00:02:17,250 --> 00:02:23,130
Why am I returning zero, remember, the three steps of Testerman development is first you have to write

22
00:02:23,130 --> 00:02:24,320
a test that fails.

23
00:02:25,020 --> 00:02:26,100
Let's run the test.

24
00:02:31,000 --> 00:02:31,900
And it feels.

25
00:02:33,890 --> 00:02:38,930
If you read into the air, it expected nineteen point two, but what we got back was zero.

26
00:02:42,640 --> 00:02:47,270
OK, now step two is to write the simplest code we can think of to make the test pass.

27
00:02:47,950 --> 00:02:52,120
So what I'll do is I'll create a for a loop that runs through the length of the prices array.

28
00:02:53,140 --> 00:02:55,180
Then I'm going to create a temporary variable.

29
00:03:00,230 --> 00:03:03,620
And add the price of each element to the temporary variable.

30
00:03:07,100 --> 00:03:08,240
Then I'll return temp.

31
00:03:11,210 --> 00:03:13,370
And now how do I know if my code is fine?

32
00:03:13,640 --> 00:03:14,930
Well, let's just run a test.

33
00:03:18,870 --> 00:03:24,690
And while it fails, I must have made a mistake, I must have a bug, it was expecting nineteen point

34
00:03:24,690 --> 00:03:27,000
two, but the function returned eighteen.

35
00:03:27,570 --> 00:03:28,260
That's a bug.

36
00:03:28,620 --> 00:03:33,570
And the beauty about unit testing is I can keep testing my logic until it works.

37
00:03:34,080 --> 00:03:35,300
So let's find out what's wrong.

38
00:03:35,670 --> 00:03:37,050
I'm going out of breakpoint here.

39
00:03:43,420 --> 00:03:50,560
And I see if I say temp is equal to zero, it keeps typecasting the double to a whole number and eventually

40
00:03:50,560 --> 00:03:55,650
the test is going to fail because when you remove the decimal places, the answer becomes inaccurate.

41
00:03:59,900 --> 00:04:01,250
So I'm going to fix my code.

42
00:04:10,770 --> 00:04:12,000
Run my unit test.

43
00:04:13,960 --> 00:04:17,950
And we get a checkmark, click on it and beautiful.

44
00:04:18,850 --> 00:04:22,180
I hope you can now see how unit testing helps you avoid bugs.

45
00:04:22,480 --> 00:04:25,930
I genuinely made the mistake of making this an inert variable.

46
00:04:26,240 --> 00:04:27,520
I wasn't paying attention.

47
00:04:27,520 --> 00:04:33,820
And the unit test told me that there is a problem in this unit of my code and it said make sure to fix

48
00:04:33,820 --> 00:04:33,990
it.

49
00:04:34,240 --> 00:04:34,960
And so I did.

50
00:04:37,390 --> 00:04:37,940
Now we're done.

51
00:04:37,960 --> 00:04:41,240
Step two, can we refactor, can the code be made simpler?

52
00:04:41,560 --> 00:04:47,160
Yes, instead of a loop, you can use a stream, but you haven't learned the streams yet.

53
00:04:47,170 --> 00:04:51,930
So for now, given what we know, I can't think of a simpler way to accomplish this.

54
00:04:51,940 --> 00:04:52,620
So that's it.

55
00:04:55,930 --> 00:04:58,210
Now we're going to write a unit test for the second case.

56
00:05:03,800 --> 00:05:05,420
Right, the test annotation.

57
00:05:08,600 --> 00:05:14,810
And this unit test is going to check if tax gets calculated during the check up process is valid, public

58
00:05:14,810 --> 00:05:16,640
void tax is valid.

59
00:05:20,730 --> 00:05:22,500
We can start off by making an assertion.

60
00:05:25,260 --> 00:05:27,750
If I call Maine, get tax.

61
00:05:29,560 --> 00:05:33,820
And passing a subtotal of 30, what's 13 percent of 30?

62
00:05:36,440 --> 00:05:39,050
So the value that we're expecting is three point nine.

63
00:05:43,230 --> 00:05:49,410
So what value is get tax going to produce first al-Qaida function called get tax?

64
00:05:55,370 --> 00:05:58,670
And according to our unit test, it should accept a subtotal.

65
00:06:02,250 --> 00:06:03,930
So for now, just return zero.

66
00:06:06,580 --> 00:06:12,520
Why am I returning zero again, remember that three steps of Testerman development first, right, a

67
00:06:12,520 --> 00:06:13,540
test that fails.

68
00:06:13,970 --> 00:06:14,980
Let's run the test.

69
00:06:21,640 --> 00:06:26,530
And it fails if you read into the error, it tells you the assertion failed, it expected three point

70
00:06:26,530 --> 00:06:28,630
nine, but the result it got was zero.

71
00:06:29,140 --> 00:06:33,620
So now step two is to write the simplest code we can think of to make this test pass.

72
00:06:34,090 --> 00:06:37,960
So what I'll do is I'll return the parameter time zero point one three.

73
00:06:47,940 --> 00:06:52,690
OK, now how do I know if my coat is fine, let's run a test and it fails?

74
00:06:52,710 --> 00:06:54,240
OK, I wasn't expecting that.

75
00:06:54,270 --> 00:06:55,260
Let's see what happens.

76
00:06:55,500 --> 00:06:57,870
OK, and that's the issue with doubles.

77
00:06:57,870 --> 00:07:02,220
When you start multiplying and dividing, you'll get a lot of decimal places.

78
00:07:02,550 --> 00:07:07,270
Sometimes the zeros can keep going forever and then at the end it gets out of whack.

79
00:07:07,680 --> 00:07:10,890
So what I have to do is keep fixing my code until the test works.

80
00:07:11,340 --> 00:07:13,930
In this case, the problem is the infinite zeros.

81
00:07:14,190 --> 00:07:17,880
So what I need to do is convert the price to two decimal places.

82
00:07:18,630 --> 00:07:23,910
This is where you can go and stack overflow and look up how to round a double to decimal places.

83
00:07:27,320 --> 00:07:28,490
I don't like this answer.

84
00:07:32,350 --> 00:07:33,550
I don't like this answer.

85
00:07:38,480 --> 00:07:44,150
OK, we can create a new object of the decimal format class, and in the constructor we can specify

86
00:07:44,150 --> 00:07:50,120
the number of decimal places and then it appears we can use a format function call must do just that.

87
00:07:55,710 --> 00:07:58,650
I'm going to put a new object to the decimal format class.

88
00:08:05,230 --> 00:08:07,930
And inside, I'm going to pass in two decimal places.

89
00:08:13,050 --> 00:08:16,380
And then we can format the tax to be two decimal places.

90
00:08:27,880 --> 00:08:30,340
And it returns a string, OK, that's not good.

91
00:08:32,780 --> 00:08:38,030
But remember, from a string, we can pass a double, so here I can say double Dutch pass double.

92
00:08:41,159 --> 00:08:44,280
And we'll pass a decimal from the following string.

93
00:08:46,270 --> 00:08:47,830
Kate, now I can run my unit test.

94
00:08:51,870 --> 00:08:54,720
And we get a checkmark, click on it and beautiful.

95
00:08:55,400 --> 00:08:58,600
I hope you can see how unit testing helps you avoid bugs.

96
00:08:58,920 --> 00:09:02,960
It literally doesn't let you continue until you fix all of your mistakes.

97
00:09:03,630 --> 00:09:04,180
So we're done.

98
00:09:04,200 --> 00:09:06,060
Step two, can we refactor?

99
00:09:07,250 --> 00:09:11,590
Not really, I can't think of a simpler way to accomplish this, so that's it.

100
00:09:15,060 --> 00:09:17,370
Now we're going to write a unit test for the third case.

101
00:09:18,690 --> 00:09:20,250
Right, the test annotation.

102
00:09:22,850 --> 00:09:29,660
And this unit test is going to check if the total equals subtotal plus tax, I'll call it total is valid.

103
00:09:37,880 --> 00:09:39,890
OK, we can start off by making an assertion.

104
00:09:45,090 --> 00:09:47,910
If I call main get total, let's say.

105
00:09:52,960 --> 00:09:59,110
And passing a subtotal of one hundred and a tax of 13, the value that we're expecting is one hundred

106
00:09:59,110 --> 00:09:59,770
and thirteen.

107
00:10:03,690 --> 00:10:06,210
So what value is that total going to produce?

108
00:10:07,180 --> 00:10:09,610
First, create a function called Get Total.

109
00:10:15,670 --> 00:10:20,470
And according to our unit test, it should accept a subtotal and attacks.

110
00:10:27,080 --> 00:10:28,760
For now, just return zero.

111
00:10:34,590 --> 00:10:40,470
And why am I returning zero again, remember, the three steps of the first step is to write a test

112
00:10:40,470 --> 00:10:41,160
that fails.

113
00:10:41,580 --> 00:10:42,540
Let's run the test.

114
00:10:48,000 --> 00:10:53,850
And it fails if you read into the error, it tells you the assertion failed, expected one 13, but

115
00:10:53,850 --> 00:10:54,510
was zero.

116
00:10:55,680 --> 00:10:59,940
Step two is to write the simplest code we can think of to make this test pass.

117
00:11:00,540 --> 00:11:04,500
So what I'll do is I'll return parameter one plus parameter to.

118
00:11:08,210 --> 00:11:10,280
OK, how do I know if my coat is fine?

119
00:11:10,310 --> 00:11:11,360
Let's run a test.

120
00:11:18,260 --> 00:11:24,170
And it passes beautiful, we're done step two, step three is to refactor the code.

121
00:11:26,760 --> 00:11:30,330
Can I make this code any shorter than it is impossible?

122
00:11:30,390 --> 00:11:30,900
We're done.

123
00:11:32,400 --> 00:11:38,820
This code is modular, which makes it easy to test because every small unit of our app has its own test.

124
00:11:45,960 --> 00:11:48,840
There are no bugs because every test passes.

125
00:11:57,840 --> 00:12:03,990
This code is expressive and it's easy to understand whoever sees this, they can easily understand what's

126
00:12:03,990 --> 00:12:04,620
going on.

127
00:12:08,040 --> 00:12:13,830
And this code is very easy to scale if I ever decide to add something to my code and by accident, I

128
00:12:13,830 --> 00:12:14,700
make a mistake.

129
00:12:19,430 --> 00:12:22,190
The test for that particular unit is going to fail.

130
00:12:22,610 --> 00:12:24,980
It tells me, hey, what, you decided to remove it?

131
00:12:40,300 --> 00:12:44,890
And just like that, we can easily scale and add more code to the application without having to worry

132
00:12:44,890 --> 00:12:46,000
about getting bugs.

133
00:12:52,220 --> 00:12:57,920
To recap, euro code using test driven development and test driven development means writing tests before

134
00:12:57,920 --> 00:12:58,670
writing code.

135
00:12:58,910 --> 00:13:00,520
And there are three steps.

136
00:13:00,920 --> 00:13:03,500
First, write code to make the test fail.

137
00:13:04,070 --> 00:13:10,180
Write the simplest code you can think of to make the test pass and then refactor the code if it's necessary.

138
00:13:12,440 --> 00:13:17,780
We use this technique to write code for a check out process, and the resulting code is highly polished.

139
00:13:18,230 --> 00:13:21,980
Our code is modular, easy to test, immune to bugs.

140
00:13:22,190 --> 00:13:24,890
It's very easy to understand and it's scalable.