Another key point behind the real wordle game
is that after each successful submission,
the game presents the player with some feedback.
It shows the correct letters in green.
It also shows letters that exist in the world
but are in the wrong spot, in yellow.
And finally, letters that don't exist in the world at all, show up in gray.
Let's implement that for our game, as well.
But before we start, there is one small refactor I want to do.
I want to separate the concerns between,
typing a guess and submitting the guess
into two different test helpers.
Effectively, this function over here represents the player
typing and submitting a guess.
So let's rename that.
If we run our tests, we can see that we're still passing.
Let's make a commit.
Rename method.
I now want to create the helper method just for typing.
And it effectively represents these lines over here.
So let's start by first inlining the guess-input.
And then I can extract this chunk over here
into a new method that will be playerTypesGuess.
This one over here will represent the player pressing enter.
Okay. If we run the tests, we can see that we're still passing.
Amazing. So let's make another commit.
Separate helper methods
for typing and submitting guesses.
We can even refactor a past test of ours
to make use of the newly made playerTypeGuess method.
Since this test isn't truly related to the process of submitting a test.
Run the tests and see that they are all passing.
All right. Let's make another commit.
Stop submitting guess in tests related to guesses in progress.
Okay. Let's write our new feature test now.
I'll be making a brand new describe block
responsible for tests related to displaying hints to the player.
Our first test for the describe block
could ensure that hints are not displayed until the player submits a guess.
And how could we write this test?
Well, a feedback or hint
is going to be represented by this special HTML attribute
called data-letter-feedback.
So maybe we can start our test
by checking that our component is not providing any hints at all at the start.
By the way, if you want to provide a nice assertion failed message,
you can enter a second argument to the expect function.
So let's say in this case,
I want a message that says
Feedback was being rendered before the player started typing their guess.
All right. Now, I want our player to start typing their guess
and even as they are typing it,
they should not be seeing hints showing up.
So let's have our player type
any guess, o I'm going to go with the word of the day for now.
And in this case, they should still not see the data-letter-feedback.
So what I'm going to do is just change the dedicated error message
to say feedback was rendered while the player was typing their guess.
Finally, I want my player to submit their guess
and only then I want to be seeing data-letter-feedback being rendered.
And in this case, I'm going to say that feedback was not rendered
after the player submitted their guess.
Please note that we are not testing styling.
Our application is responsible
for marking certain DOM elements with this specific HTML attribute.
But our tests do not care about what CSS rules might be applied
to these attributes.
Another thing that I want to mention is that this test over here we just wrote,
violates that arrange, act,
and assert structure I presented in the first few lessons of this course.
This could be considered a smell.
This assertion over here that is happening before the act phase
is what we call a pre-assertion.
We could have turned this pre-assertion into a dedicated test,
called the game starts with no hints being displayed.
This middle assertion over here could also be a dedicated new test
called no hints are displayed while the user types a guess.
Finally, this final assertion over here
could be a test called hints are displayed after a guess is submitted.
Therefore, this test over here represents three tests built into one.
I did want to present it like this in this lesson
because I thought this would be a good opportunity for us to cover
custom error messages
and also because there have been certain cases in my career as a developer
where I come to conclude that having a test with multiple assertions
was providing greater readability to my test switch.
With that said, for this particular case over here,
I would personally prefer to split this test into three different ones,
but I'll keep this code base exactly like this,
which one do you prefer?
Would you like to split this test over here into multiple ones?
Try it out. It's definitely a valid approach.
If we run our tests, we can see that we're failing
because feedback was not rendered after the player submitted their guess.
To get it to pass, we could make use of our shouldFlip prop
we wrote in the last episode.
After all, it's through flipping the cards
that the wordle game presents feedback to their player.
Well, right now, our tests
are only enforcing that we should write any kind of feedback at all.
So, what I'm going to do is, if should flip is provided and truthy,
I'll render a feedback of unknown.
If should flip is false, I'll not render a feedback.
If I run the tests, we can see that we're now passing.
Let's make a commit.
Display unknown feedback upon successful guess submission.
For refactoring, we could argue that shouldFlip is a pretty bad name,
since flipping is just a stylistic choice for how we review the feedback.
We could maybe rename this prop to shouldShowFeedback instead.
This would probably be a much better name for a boolean prop with this role.
With that said, I won't do this renaming right now,
because our next test will be driving us towards providing proper feedback
in accordance to the word of the day,
so a boolean prop will simply not be enough.
Great! Not only we refactored our codebase a little bit more,
but we also began to enforce that letter feedback
should only be given once a guess is successfully submitted.