1
00:00:05,020 --> 00:00:07,200
Before we start writing our tests,

2
00:00:07,225 --> 00:00:10,967
I want us to make one quick
update to our configurations.

3
00:00:11,267 --> 00:00:15,733
Vitest allows us to make use
of their functions such as describe,

4
00:00:15,833 --> 00:00:21,083
expect, and it without having
to import them ourselves,

5
00:00:21,100 --> 00:00:26,093
every time we need them.
Τo do this, we need to enable globals.

6
00:00:26,653 --> 00:00:30,267
We can do so by going
to our vitest.config

7
00:00:30,600 --> 00:00:34,480
and setting the flag
of globals to true, like this.

8
00:00:39,205 --> 00:00:41,508
Finally, since we were using typescript,

9
00:00:41,533 --> 00:00:47,100
we should let the interpreter know
that vitest globals are available.

10
00:00:47,533 --> 00:00:51,800
To do this, we need to go
to our tsconfig.vitest.json,

11
00:00:51,926 --> 00:00:57,090
and add an extra type vitest/globals.

12
00:00:59,650 --> 00:01:05,467
Perfect. Now we can go back to our test
and delete this import statement.

13
00:01:06,553 --> 00:01:07,930
If I try running them,

14
00:01:08,406 --> 00:01:10,903
you can see they were still passing.

15
00:01:14,910 --> 00:01:17,967
Great. We should be good
to make a commit now.

16
00:01:18,883 --> 00:01:22,867
Now, I'm gonna call this commit,
use vitest globals.

17
00:01:25,320 --> 00:01:28,300
Now let's start writing our first test.

18
00:01:28,747 --> 00:01:30,550
As we coverage in the first lesson,

19
00:01:30,575 --> 00:01:33,196
a key principle behind
test driven development

20
00:01:33,221 --> 00:01:36,021
is the red green
refactor development loop.

21
00:01:36,767 --> 00:01:38,567
This means that the very first step

22
00:01:38,600 --> 00:01:41,387
will take to get
our worldle game implemented

23
00:01:41,413 --> 00:01:44,586
is to write the first test
with our requirements

24
00:01:44,600 --> 00:01:46,713
we want our application to fulfill.

25
00:01:47,367 --> 00:01:49,433
Since we're making a world clone,

26
00:01:49,458 --> 00:01:52,033
I would say that a good first requirement

27
00:01:52,058 --> 00:01:57,370
could be that if a user makes a guess
that matches the word of the day,

28
00:01:57,395 --> 00:02:00,167
we should show them a victory message.

29
00:02:00,446 --> 00:02:01,566
Let's do this.

30
00:02:01,712 --> 00:02:03,917
When I'm thinking about a name for a test,

31
00:02:03,942 --> 00:02:06,333
I like to come up with a name that,

32
00:02:06,358 --> 00:02:09,200
even somebody who is a judge
developer can understand.

33
00:02:10,066 --> 00:02:14,833
Furthermore, I try to avoid
using words like correct and incorrect,

34
00:02:15,200 --> 00:02:18,667
because by themselves,
they don't carry a lot of meaning.

35
00:02:18,692 --> 00:02:23,767
I like to explain what it means
to be correct in my task name.

36
00:02:24,833 --> 00:02:27,100
For example, in this case over here,

37
00:02:27,125 --> 00:02:33,133
I would say that a reasonable test name
could be test a victory message appears

38
00:02:33,158 --> 00:02:37,200
when the user makes a guess
that matches the word of the day.

39
00:02:37,440 --> 00:02:38,610
Let's type it out.

40
00:02:44,930 --> 00:02:45,967
Perfect.

41
00:02:46,953 --> 00:02:48,300
To write this test,

42
00:02:48,325 --> 00:02:52,483
we need to first arrange the environment
with all the initial conditions

43
00:02:52,500 --> 00:02:55,533
that are needed
to put our test in a good stage.

44
00:02:56,033 --> 00:03:01,067
In our case here,
we need to prepare a wordle board component

45
00:03:01,460 --> 00:03:04,467
with a given word of the day.

46
00:03:04,667 --> 00:03:09,467
I decided to arbitrarily choose
the word of the day to be tests.

47
00:03:09,673 --> 00:03:11,708
Now, what we need to make sure

48
00:03:11,733 --> 00:03:15,467
is that since our user
is gonna be making a guess that matches,

49
00:03:16,067 --> 00:03:18,267
when we get to the act phase,

50
00:03:18,300 --> 00:03:22,630
our user is gonna be typing
exactly this word.

51
00:03:22,655 --> 00:03:27,567
But great, so this over here is enough
to finish our arrange phase.

52
00:03:28,767 --> 00:03:30,967
Now yes, let's move on to the act phase.

53
00:03:31,000 --> 00:03:35,173
In the act phase,
we are going to perform the actions

54
00:03:35,198 --> 00:03:37,087
that the user is going to be doing.

55
00:03:37,112 --> 00:03:40,200
That will drive a response
from our application.

56
00:03:40,333 --> 00:03:45,033
In this case over here,
our player is going to type a guess,

57
00:03:45,213 --> 00:03:47,133
and then they're gonna submit it.

58
00:03:48,133 --> 00:03:49,717
How should they submit their guess?

59
00:03:49,733 --> 00:03:52,203
Maybe pressing on a button?

60
00:03:52,333 --> 00:03:56,933
I'm gonna go with,
they can press enter if they type a guess,

61
00:03:56,933 --> 00:03:58,433
as soon as they press enter.

62
00:03:58,540 --> 00:04:02,333
The game is gonna interpret us
they are submitting their guess.

63
00:04:02,358 --> 00:04:06,100
So, first, let's identify the input

64
00:04:06,125 --> 00:04:08,083
that the player
is gonna be interacting with.

65
00:04:08,133 --> 00:04:12,967
I'm just saying here that I'm finding
an input that takes text.

66
00:04:13,467 --> 00:04:17,856
Now we want our player to be typing
into that input and to do this,

67
00:04:17,881 --> 00:04:21,529
With vue/test-utils
we can use the function such value.

68
00:04:22,267 --> 00:04:24,033
Notice how I'm having our player

69
00:04:24,058 --> 00:04:26,900
type exactly
the word of the day as their guests.

70
00:04:27,200 --> 00:04:29,967
Finally, we want our player
to press enter,

71
00:04:29,992 --> 00:04:32,067
so that they can submit their guess.

72
00:04:32,833 --> 00:04:36,533
We can do this by using the trigger
function from vue/test-utils

73
00:04:38,107 --> 00:04:43,267
And perfect. We have finally
finished the act phase of our test.

74
00:04:43,966 --> 00:04:47,400
Now we are ready to perform our assertion.

75
00:04:48,013 --> 00:04:51,167
How should the application
respond to this?

76
00:04:51,200 --> 00:04:53,333
As the test name describes?

77
00:04:53,358 --> 00:04:55,633
We expect a victory message to appear.

78
00:04:55,658 --> 00:05:00,167
Let's just hope that a message that says,
you won, shows on the screen.

79
00:05:00,270 --> 00:05:04,936
To do this, one thing that we can do
is just a assert over all the text

80
00:05:04,961 --> 00:05:07,067
that is being rendered by that component.

81
00:05:07,133 --> 00:05:08,700
We can do it like this.

82
00:05:13,620 --> 00:05:19,033
Now, if we run our tests,
we can see that it is immediately failing.

83
00:05:21,343 --> 00:05:24,800
And the reason
for the failure is that first,

84
00:05:24,867 --> 00:05:27,570
we were missing
a required prop of message.

85
00:05:28,676 --> 00:05:34,500
And also, it could not call the set
value function in an empty DOMWrapper.

86
00:05:34,700 --> 00:05:38,133
This means
that there was no input of type text

87
00:05:38,166 --> 00:05:40,003
being rendered to the screen.

88
00:05:40,613 --> 00:05:42,293
Let's fix these errors.

89
00:05:43,690 --> 00:05:45,533
If we go to our component,

90
00:05:46,807 --> 00:05:49,573
you can see over here
that we do have a prop of message,

91
00:05:49,598 --> 00:05:51,727
that's what came from the boilerplate.

92
00:05:51,987 --> 00:05:55,867
Let's rename this to word of the day.

93
00:05:59,650 --> 00:06:03,300
And also, let's make sure that in app.vue,

94
00:06:03,400 --> 00:06:07,063
we are also using
the word of the day prop now,

95
00:06:07,227 --> 00:06:10,667
because we just changed it
in our component.

96
00:06:11,500 --> 00:06:14,923
By the way, I tend to prefer
to use kebab case for props,

97
00:06:15,467 --> 00:06:16,883
choose whatever you prefer.

98
00:06:16,908 --> 00:06:18,600
It's just a matter of style.

99
00:06:20,542 --> 00:06:22,600
Okay, of course we're still failing

100
00:06:22,633 --> 00:06:26,267
because we still don't have
the inputs of type text.

101
00:06:26,767 --> 00:06:31,600
So let's get that rendered
to the screen as well.

102
00:06:34,603 --> 00:06:39,867
If I run my test now, I can see
that I'm failing for a new reason.

103
00:06:40,339 --> 00:06:45,567
I expected they were the sentence
of you want to be rendered to the screen,

104
00:06:45,567 --> 00:06:48,437
but I can only see the word tests.

105
00:06:48,467 --> 00:06:51,203
And that's because
we're rendering the prop, right here.

106
00:06:52,717 --> 00:06:56,533
To get it to pass, what is the least
amount of work necessary?

107
00:06:59,302 --> 00:07:04,767
We could simply always render
the You won message.

108
00:07:05,646 --> 00:07:07,710
That's what the test
is looking for, right?

109
00:07:07,735 --> 00:07:09,233
So let's just do this.

110
00:07:09,439 --> 00:07:12,567
If I run my test again, I'm passing.

111
00:07:12,967 --> 00:07:16,600
Now, you must be thinking
that we're cheating, right?

112
00:07:16,667 --> 00:07:20,900
After all, the test was asking us
to render the victory message.

113
00:07:21,000 --> 00:07:23,633
When the player guesses correctly,

114
00:07:24,233 --> 00:07:27,533
we're just rendering
the victory message all the time.

115
00:07:28,193 --> 00:07:29,690
It might look silly,

116
00:07:29,800 --> 00:07:35,157
but this concept of doing the very least
amount of work necessary is critical.

117
00:07:35,182 --> 00:07:39,667
And it protects us against
two main issues, over abstraction,

118
00:07:39,700 --> 00:07:45,500
which is over complicating things
before they even need to be complicated.

119
00:07:45,867 --> 00:07:49,667
And having a test suite
that is not robust enough.

120
00:07:50,367 --> 00:07:53,050
And I would say
that in our case right now,

121
00:07:53,086 --> 00:07:55,733
we're suffering from the second scenario.

122
00:07:57,226 --> 00:08:01,453
Our test suite is tiny.
It's just a single test.

123
00:08:01,478 --> 00:08:04,823
We can refine it more
as we're working on this project.

124
00:08:05,220 --> 00:08:09,333
But for the moment,
just always rendering the victory message

125
00:08:09,400 --> 00:08:11,023
is good enough.

126
00:08:11,033 --> 00:08:14,700
We are fulfilling
the requirements of this task.

127
00:08:15,199 --> 00:08:18,700
Great. Now that the tests are green,
let's make a commit.

128
00:08:20,090 --> 00:08:24,767
Whenever I'm having a hard time thinking
of what my commit message should be,

129
00:08:25,033 --> 00:08:28,967
I like to look into the name
of the task that I just wrote,

130
00:08:29,386 --> 00:08:34,177
because, the core part
of the work I've just done,

131
00:08:34,400 --> 00:08:37,730
was to focus
on getting these tests to pass, right?

132
00:08:37,833 --> 00:08:42,067
So I was working on the features required

133
00:08:42,100 --> 00:08:44,270
to fulfill the requirements of this task.

134
00:08:45,017 --> 00:08:49,600
So in this case, maybe we could say
that render victory message

135
00:08:51,957 --> 00:08:55,500
is a valid description
of what we just worked on.

136
00:08:58,097 --> 00:09:02,400
Great. At this point,
we have successfully gone through the red,

137
00:09:02,467 --> 00:09:03,803
and the green phase.

138
00:09:03,833 --> 00:09:06,833
Now, we're about to enter
the reflector phase.

139
00:09:07,046 --> 00:09:12,467
This is where we can make our code
easier to understand and maintain.

140
00:09:13,227 --> 00:09:15,733
There are a couple of tricks
that we can use.

141
00:09:16,400 --> 00:09:22,180
There is this amazing workshop
from Woody Zuill and Llewellyn Falco,

142
00:09:22,205 --> 00:09:25,333
where they discuss a couple
of strategies for refractory.

143
00:09:25,358 --> 00:09:27,433
I've included the link in the description.

144
00:09:27,666 --> 00:09:32,700
But in short, one of the things
that they look for, is clutter.

145
00:09:33,133 --> 00:09:34,606
And what is clutter?

146
00:09:34,633 --> 00:09:38,530
Clutter is anything
in your code base that is useless.

147
00:09:38,555 --> 00:09:40,300
It's just taken up space.

148
00:09:40,486 --> 00:09:43,023
I would argue, for example, that,

149
00:09:43,100 --> 00:09:45,073
these comments over here
that are included

150
00:09:45,098 --> 00:09:50,333
to describe the different test phases,
are not useful. So let's delete them.

151
00:09:52,767 --> 00:09:56,633
If I run my task again,
you can see that we're still passing.

152
00:09:56,658 --> 00:10:00,058
Great. Let's make a commit,
remove clutter.

153
00:10:01,172 --> 00:10:05,967
Another thing that Woody Zuill
and Llewellyn Falco suggest looking for,

154
00:10:06,000 --> 00:10:08,305
is reducing complexity.

155
00:10:08,600 --> 00:10:12,567
And there are a couple of things
that we can account for

156
00:10:12,592 --> 00:10:14,113
in regards to complexity.

157
00:10:14,133 --> 00:10:19,400
But one of them is magic numbers
or magic strings.

158
00:10:19,553 --> 00:10:25,300
I would say that this You won! message
would be an example of a magic string.

159
00:10:26,643 --> 00:10:31,250
One of the things that we can do in here
is extract a common constant

160
00:10:31,275 --> 00:10:36,400
that is going to be used
both by our test and by our water board.

161
00:10:37,486 --> 00:10:39,000
So let's do this.

162
00:10:43,297 --> 00:10:46,500
I'm gonna make a file called settings.

163
00:10:48,597 --> 00:10:50,300
At the base of the project,

164
00:10:50,540 --> 00:10:54,340
And this is going to contain
this constant over here that can be recorded.

165
00:10:57,747 --> 00:11:00,443
I also wanna do the same thing for our,

166
00:11:01,783 --> 00:11:03,433
that's not what I want.

167
00:11:03,767 --> 00:11:06,633
I also want to do the same thing
for our wordle word.

168
00:11:06,807 --> 00:11:12,500
Let's just in here,
render victory message.

169
00:11:15,403 --> 00:11:19,067
And perfect. There we go.
So if we run the tests,

170
00:11:19,599 --> 00:11:22,000
we can see there were still passing.

171
00:11:22,803 --> 00:11:26,700
So let's make a commit
and call that extract constant.

172
00:11:29,017 --> 00:11:32,433
Amazing.
We just finished our first TDD loop.

173
00:11:32,620 --> 00:11:35,067
We wrote a test, we got it to pass,

174
00:11:35,100 --> 00:11:37,467
and then we cleaned up
our code a little bit

175
00:11:37,533 --> 00:11:40,100
to increase the maintainability
of the code base.

176
00:11:40,513 --> 00:11:43,533
Now, let's start the process
all over again.