1
00:00:04,747 --> 00:00:07,633
I think a good thing
we could enforce next

2
00:00:07,658 --> 00:00:13,337
is that a defeat message appears
if the user makes an incorrect guess.

3
00:00:13,673 --> 00:00:17,343
I realize wordle allows you
to make multiple mistakes,

4
00:00:17,400 --> 00:00:21,533
but I want to keep things simple for now.

5
00:00:21,619 --> 00:00:24,233
Let's just say that in our worldle game,

6
00:00:24,258 --> 00:00:27,100
if you make a correct guess,
you win the game.

7
00:00:27,200 --> 00:00:31,203
If as soon as you make your first
incorrect guess, you lose the game.

8
00:00:31,950 --> 00:00:36,200
Most test frameworks allow you
to write placeholder tests

9
00:00:36,546 --> 00:00:40,233
where we can just type down
ideas for the future.

10
00:00:40,759 --> 00:00:43,677
Vitest is not an exception to that.

11
00:00:43,967 --> 00:00:50,733
We can write placeholder test in vitest,
by adding the word todo after the test.

12
00:00:51,513 --> 00:00:55,633
In this case, let's just write
two difference todo tests here.

13
00:00:55,800 --> 00:00:58,757
One that says a defeat message appears

14
00:00:58,767 --> 00:01:01,667
if the user
makes a guess that is incorrect.

15
00:01:04,517 --> 00:01:08,767
Another one that says
that no range of game message appears

16
00:01:08,833 --> 00:01:11,933
if the user has not yet made a guess.

17
00:01:15,777 --> 00:01:19,300
Great. Do you wanna try writing
this test down yourself?

18
00:01:20,000 --> 00:01:22,100
Post this video and try it out?

19
00:01:23,683 --> 00:01:28,433
Okay. Let's write the implementation
of our first todo.

20
00:01:31,957 --> 00:01:34,577
I think a lot
of the heavy lifting for this task

21
00:01:34,800 --> 00:01:38,567
can be copied over
from the previous test that we have.

22
00:01:42,646 --> 00:01:44,367
All we want to change in here

23
00:01:44,400 --> 00:01:49,067
is that instead of making a guess
that matches the word of the day,

24
00:01:49,167 --> 00:01:51,767
let's make a guess that doesn't.

25
00:01:54,450 --> 00:01:56,929
Finally, for our search phase,

26
00:01:56,954 --> 00:02:01,667
I want to assert
that we see a defeat message.

27
00:02:03,360 --> 00:02:06,167
Let's go with better luck next time.

28
00:02:09,193 --> 00:02:11,047
If we run our tests,

29
00:02:13,120 --> 00:02:16,175
we can see
that we are passing on the first test,

30
00:02:16,200 --> 00:02:18,920
but in this new one, we are failing.

31
00:02:19,019 --> 00:02:21,867
We expected to see better luck next time.

32
00:02:22,046 --> 00:02:24,167
But we saw You won!,

33
00:02:25,800 --> 00:02:27,913
by the way, as a rule of thumb,

34
00:02:28,000 --> 00:02:30,633
always run the entire test switch.

35
00:02:30,706 --> 00:02:34,687
Even if you think exactly
which tests are being affected,

36
00:02:34,712 --> 00:02:36,360
by the work that you are doing,

37
00:02:36,700 --> 00:02:41,100
running the entire test switch
will protect you against regressions.

38
00:02:42,683 --> 00:02:44,567
To get this test to pass.

39
00:02:44,665 --> 00:02:49,367
We can do the same approach
that we've done for the victory message.

40
00:02:49,600 --> 00:02:54,743
Let's just go to our wordle board
and always render the defeat message.

41
00:02:57,570 --> 00:03:03,033
So if we run our tests, we can see
that we're back to the green stage.

42
00:03:03,058 --> 00:03:04,533
Let's make a commit.

43
00:03:08,343 --> 00:03:10,167
Display defeat message.

44
00:03:13,556 --> 00:03:18,700
Now, as you are probably expecting,
we are back to the refactor phase.

45
00:03:18,900 --> 00:03:23,233
I think that just like
how we've done with the victory message,

46
00:03:23,300 --> 00:03:25,500
we can reduce complexity here

47
00:03:25,525 --> 00:03:30,733
by extracting another constant
that will contain our defeat message.

48
00:03:39,430 --> 00:03:42,170
We can also do
the same thing for our test.

49
00:03:48,733 --> 00:03:52,400
If we run our test, still passing.

50
00:03:52,500 --> 00:03:55,767
Let's make a commit, extract constant.

51
00:03:59,192 --> 00:04:02,433
Another extraction we can do
is for the word of the day.

52
00:04:02,458 --> 00:04:03,818
So let's do that.

53
00:04:10,017 --> 00:04:13,763
Whenever you have a key
equals to the value in an object,

54
00:04:13,788 --> 00:04:17,295
you can just simplify it,
just having the key.

55
00:04:19,588 --> 00:04:25,800
Perfect. If we run our tests
or is still passing, that's great.

56
00:04:26,046 --> 00:04:30,167
So let's make a commit
and call this extract variable.

57
00:04:31,410 --> 00:04:36,967
Okay, now, we're ready to implement
the body of our next todo test.

58
00:04:38,577 --> 00:04:44,033
Once again, let's make use
of our existing tests as a reference.

59
00:04:44,267 --> 00:04:46,633
So, I'm going to copy the previous test.

60
00:04:47,717 --> 00:04:51,100
And in this case,
we're not doing any user input.

61
00:04:53,003 --> 00:04:56,033
And we are hoping
that we're not going to see

62
00:04:56,633 --> 00:04:58,733
neither the victory message

63
00:05:01,283 --> 00:05:03,400
nor the defeat message.

64
00:05:05,697 --> 00:05:07,977
And we are back to the red stage

65
00:05:08,002 --> 00:05:11,400
because we're seeing
those two messages all the time.

66
00:05:11,667 --> 00:05:14,577
To get this test to pass,
we'll have to do a couple of things.

67
00:05:14,633 --> 00:05:18,767
We have to keep track of the guess
that the user is about to submit.

68
00:05:18,959 --> 00:05:21,506
And once the user submits their guess,

69
00:05:21,531 --> 00:05:23,827
we will compare it.
with the word of the day.

70
00:05:24,000 --> 00:05:26,853
If they match,
we show the victory message.

71
00:05:26,867 --> 00:05:29,663
If they don't,
we show the defeat message

72
00:05:30,173 --> 00:05:33,033
to keep track of the guess
that the user is typing.

73
00:05:33,167 --> 00:05:36,767
We can make use of a ref.

74
00:05:42,009 --> 00:05:48,367
So the guessing progress
can be tracked via this ref.

75
00:05:49,733 --> 00:05:54,133
The submission happens
when the user presses the enter key.

76
00:05:54,433 --> 00:05:58,567
Let's have another ref over here
for the guess submitted.

77
00:06:01,070 --> 00:06:04,833
And when enter is pressed,

78
00:06:05,300 --> 00:06:10,000
the guess meters receives
the value of the guess in progress.

79
00:06:11,567 --> 00:06:15,083
Perfect. Now regards
to showing the messages,

80
00:06:15,153 --> 00:06:19,633
we can check to see if the guess submitted

81
00:06:21,863 --> 00:06:27,633
is equal to word of the day,
then we show victory message.

82
00:06:28,033 --> 00:06:30,833
Otherwise, we show the defeat message.

83
00:06:35,389 --> 00:06:36,990
Now, this is not gonna be enough.

84
00:06:37,015 --> 00:06:41,433
If we run our tests,
we can see that we are still failing,

85
00:06:41,460 --> 00:06:45,267
because even though
we didn't submit any guesses,

86
00:06:45,985 --> 00:06:49,569
so we are already showing
the defeat message to the user.

87
00:06:50,960 --> 00:06:53,467
This is because an empty string

88
00:06:53,660 --> 00:06:56,567
is going to be different
from the word of the day.

89
00:06:56,667 --> 00:06:58,100
That was tests.

90
00:06:59,300 --> 00:07:02,433
We're gonna have to add
an additional check in here

91
00:07:03,093 --> 00:07:05,533
that we only render the message

92
00:07:05,700 --> 00:07:10,767
if a guess has a length greater than zero.

93
00:07:14,437 --> 00:07:18,370
if you run this,
now we're in a green stage.

94
00:07:20,083 --> 00:07:22,233
Perfect. Let's make a commit.

95
00:07:23,317 --> 00:07:26,267
Only render end-of-game feedback

96
00:07:26,467 --> 00:07:28,000
after the game is over.

97
00:07:30,670 --> 00:07:35,467
Reducing duplication is one key
focus of the refractory phase.

98
00:07:36,033 --> 00:07:39,733
And we can reduce duplication
in our test suite.

99
00:07:40,146 --> 00:07:43,767
Notice that every test we have,

100
00:07:43,800 --> 00:07:47,200
it starts with exactly
the same arrange phase.

101
00:07:48,073 --> 00:07:53,767
Let's extract this common logic
into a hook that runs before each test.

102
00:07:54,333 --> 00:07:56,033
This can be done in vitest

103
00:07:56,067 --> 00:07:58,733
by writing a function called beforeEach.

104
00:07:59,733 --> 00:08:01,810
Whatever we write in this function,

105
00:08:01,833 --> 00:08:06,333
it is guaranteed to run before
every single test in this group.

106
00:08:10,743 --> 00:08:14,167
Now notice that I've made wrapper
be a variable

107
00:08:14,200 --> 00:08:17,200
that is in the context
of this describe group.

108
00:08:18,843 --> 00:08:21,590
You might notice
that our typescript configuration

109
00:08:21,600 --> 00:08:27,100
doesn't like the fact that we're using
an implicit type of any to our wrapper

110
00:08:27,125 --> 00:08:29,233
because I'm not defining
the type right now.

111
00:08:30,197 --> 00:08:33,467
But if we go to the definition
of the mount function,

112
00:08:33,780 --> 00:08:37,967
we can see that the return type
can be pretty daunting.

113
00:08:38,899 --> 00:08:40,633
Here's a little typescript hint

114
00:08:40,667 --> 00:08:44,233
that might help you a lot
when working with complex types.

115
00:08:44,567 --> 00:08:48,577
Since we know our wrapper
is always going to be containing

116
00:08:48,600 --> 00:08:50,367
whatever mount is returning,

117
00:08:51,030 --> 00:08:56,100
we can leverage a utility type
that typescript makes available for us

118
00:08:56,167 --> 00:08:58,543
specifically for this kind of scenario.

119
00:08:59,063 --> 00:09:03,443
We can type each wrapper
as the return type

120
00:09:05,217 --> 00:09:07,523
of the mount function.

121
00:09:08,767 --> 00:09:11,500
And there you go. Just like that.

122
00:09:11,800 --> 00:09:17,300
Our wrapper is explicitly typed now
to whatever the mount function returns.

123
00:09:17,353 --> 00:09:22,167
If we run all of our tests,
we can see that they are passing.

124
00:09:23,863 --> 00:09:26,050
Alright, now let's make a commit.

125
00:09:27,497 --> 00:09:31,400
Extract arrange phase to beforeEach.

126
00:09:35,757 --> 00:09:39,167
Another chunk of code
that is being repeated multiple times

127
00:09:39,200 --> 00:09:43,677
is the act of having the player type
and submit their guess.

128
00:09:44,757 --> 00:09:49,133
Let's extract this
into a custom helper message.

129
00:09:51,423 --> 00:09:56,100
And in this case, I'm gonna call
this playerSubmitGuess.

130
00:09:59,117 --> 00:10:01,967
This function, I'm gonna have the guess
that the players are meeting

131
00:10:04,277 --> 00:10:05,833
right here.

132
00:10:06,303 --> 00:10:09,067
And in this case,
we're passing the word of the day.

133
00:10:09,779 --> 00:10:15,833
In this other case, over here,
we're passing the word WRONG.

134
00:10:17,259 --> 00:10:18,667
If we run our task,

135
00:10:19,433 --> 00:10:20,967
we are still passing.

136
00:10:22,920 --> 00:10:25,130
This refractory technique over here

137
00:10:25,155 --> 00:10:28,600
that i've just done
is called extract method,

138
00:10:28,800 --> 00:10:31,000
so, because our tests are passing.

139
00:10:31,067 --> 00:10:35,467
I'm gonna make another commit
and say, extract method.

140
00:10:36,033 --> 00:10:38,200
Great. We've learned different ways.

141
00:10:38,225 --> 00:10:42,833
We can refactor our codebase
to make it easier to work with,

142
00:10:42,886 --> 00:10:46,233
with by extracting constants and methods.

143
00:10:46,413 --> 00:10:50,723
We also learned how we can leverage
beauty and hooks of vitest,

144
00:10:50,906 --> 00:10:54,227
to handle common parts
of our arranged phase.