To ensure that controls would be removed from the player
as soon as the game is over, I opted to create two new tests,
one that would ensure the player would lose control
after they've made a series of wrong guesses,
that is, they failed to win the game,
and another one that would ensure that the player loses control
once they win the game.
Both tests were written inside of the player input describe block.
For the case of losing the game,
I just had the player make six incorrect guesses in a row
and then I assert that the player input has the disabled attribute in it.
Likewise, for the case of the player winning the game,
the player will make a successful guess,
that is, their guess is going to contain the word of the day,
and just like in the previous test,
the input should also have the disabled attribute.
To get this test to pass,
I've defined an optional prop in the player input.
So you can see over here that I'm defining disabled
as an optional prop of Boolean type,
and if the user doesn't provide me with this prop,
it will default into the false value.
This prop is used directly in the native input.
So it's just immediately bound to the disabled HTML attribute.
This prop is being used by the wordleboard.
You can see over here that the disabled prop
just uses whatever value is contained
inside of our computed property isGameOver.
So as soon as the game over, the disabled prop becomes true.
Otherwise, the disabled prop is false.
For this work, I've made a commit called disableControls
if the game is over.
And as you can see, all the tests are still passing.
In regards to rendering the entire board with empty guesses
at the start of the game,
I strongly considered not writing any additional tests for this,
since I first thought that this would just be a stylistic preference
instead of a true operational requirement of the application.
But upon thinking a bit more over this, I changed my mind and I came to conclude
that the board should always show exactly how many guesses the user can make
is a requirement of the game.
But honestly, feel free to disagree with me.
Just keep in mind that the idea
is that we should be testing behavior and goals,
and this line can get a little bit blurry at times.
So here are the tests that I wrote
to enforce that there will always be six guesses view
present throughout the game.
So I made a dedicated describe block for this,
and I ensure that there will be exactly six guesses views
being rendered at the start of the game.
And this also continues to be true if the player wins the game,
and it continues to be true if the player loses the game.
So it's three different tests,
all responsible to ensuring
that the number of guess-views in the page does not change.
To get them to pass,
I've opted to create an additional group of list items.
And you can see over here
that I'm just rendering a series of empty guesses
under the view for the guess-input.
And to calculate the number of empty guesses,
I use this computed property over here
that is based on what is the MAX_GUESSES_COUNT
that the player has the right to,
and how many guesses have they submitted so far.
Of course that once the game is over,
the guess-input will not be accessible anymore,
so I also need to account for that over here.
A downside of the way I wrote these tests over here
is that I'm enforcing a given amount of guess-view components in specific.
Therefore, in a way,
the tests that I wrote over here are testing part of the implementation.
Writing tests is not an exact science,
and it's still a thing that you and I should strive to improve each day.
If you have a better suggestion
on how we should have written this test over here,
please don't hesitate to reach out.
I would love to hear your ideas.
Awesome! With this, we've made sure
our players will be able to see all the guesses that they have done,
and how many guesses they can perform in the future.
Not only that,
but we've also successfully prevented our players from submitting guesses
once the game is over,
which was a great way to explore how to disable inputs with vue
and how to test that behavior through vitest with vue test utils.