We will be very soon working with our TDD implementation
of the rules of the word of the day.
But before we do that, for the sake of time,
I want you make a file available for us.
This json file contains a list of 2,500 words
that are five letters long in the English language,
will be considering this,
as the least of the possible words to use in the game,
I have included a link in the description for you, to download this file yourself.
I have saved the file in source englishWordsWith5Letters.json.
Alternatively, if you watch,
you can clone the repository at a start position for this episode,
which should already include this file.
The link to the repository is also in the description.
Alright? I think we are at a good point to start writing more tests.
This time, let's define the rules for the word of the day.
Let's start with the cases in which we are providing the application
with an invalid word of the day, and because of that,
the application should be displaying a warning.
So let's write a test for
if a word of the day provided does not have exactly five letters,
a warning should be immediate.
For this, we can start our test
by mounting the wordleBoard component with a word of the day
that has less than five characters.
I'll be using FLY.
Now, we want this action to return in a console warning being called,
one way for us to know what's going on with the console warn
while the tests are running,
is by making use of a spy.
As the name implies,
the spy will not be interfering with the execution of the function.
It's a spy on. It will simply be keeping an eye on it.
Will then be able to ask questions
and build assertions by interaction with the spy.
To deploy a spy towards the worn function,
from the console object, we can write vi.spyOn(console, "warn").
It's important that we deploy a spy before we take the action
that is supposed to cause console warn to be involved.
So to do this, I'm gonna move the spy on to before we mount the components.
Finally, we can make assertions on this function.
Thanks to our spy.
If we run the test,
as we can see over here, the console warn has not been called at all.
To get these tests to pass, we can make use of vue prop validators.
To use this, we need to provide a function callback
to the validator key in our proper definition.
If this function returns true, the prop given will be considered valid.
If it returns false, it will be considered invalid.
In our case, let's write a validation function,
forces the length of the words given to be exactly five characters.
And great, our tests are passing.
Let's make a commit.
I think a good commit message, in this case, could be,
enforce that the word of the day must have 5 characters.
However, please notice
that a console warn is showing up for real when we run our tests.
This adds some clutter to the task output.
I don't want to have this console warning showing up in our tests output.
Let's reflect our test, to instead,
replace the console warn with a test double that does absolutely nothing.
I do wanna mention that the lines are a little bit blurred
when they were working with vitest.
And Jest and then the spy on vitest,
can indeed mock implementation. if you wanted to do so.
Like this, we can capture this spy, over here.
And then through the spy, we can mock the implementation
to just be a function that doesn't do anything.
If I run the task now,
you can see that we no longer have that console warning showing up
for real in our tests.
And we can still do the assertions on edge.
Another way we could do this without relying on the spy
would be by mocking the console warn,
function directly by using vi.fn which is my personal preference,
since it distinguishes they spy from the mock.
To do so, as part of our setup,
we can do console.warn=vi.fn.
If we run our tests, we can see that they are still passing
without the clutter in our console output.
So let's make a commit replaces by for mock could be a good commit message.
Now, how about the next test?
I think a good thing that we can check for
is that the word of the day must be all in uppercase.
So test, if the word of the day is not all in uppercase,
a warning is immediate.
Do you wanna try running this test yourself?
If you're interested,
try pausing the video now and write a test solution on your own.
Okay, so here is how I would do it.
I would pretty much just copy exactly what I wrote on the previous task.
But instead of mounting it with a word that has less than five characters,
I'm gonna write a word that has five characters,
but it's using lowercase characters.
Right? If I run this test over here,
and you can see that now we're failing,
because our console warn has not been called.
Right? to get it to pass, we just need to improve our validator
to now enforce that all the characters should be in uppercase.
Now let's go to the wordle board and add that to our validator
for run out the tasks again.
And we're passing great. So, let's make another commit.
And this would be enforced that the word of the day must be all in uppercase.
Another test that I would like us to have
is that if you provide a word of the day that is just gibberish,
so it's not a real world in English, we should also get a warning.
To do this, let's just copy the previous test.
And let's just say that if the word of the day is not a real word,
a warning is immediate.
Perfect, and then in here, let's just type a word that is only an uppercase
that has five characters, but doesn't exist.
Run all the tests again, and remember always run all the tests.
Perfect. We don't see a warning here.
Now, to get this test to pass,
we need to import the data from that json file,
I was showing at the start of the episode.
And to facilitate working with json,
we can update our ts config file.
So, if you go to your ts, configure the root of the project,
on the app,
we can add to the compiler options, resolve json modules.
So let's enable that, it's usually disabled by default.
And we also want to include json files
in here.
Great. Now we should be able to import json files
As a regular default import.
Let's go back to our component
and check if the word given exists within the list of words
that we have in that json file.
How would we do this?
We can start by importing our Json file in here.
And we can add to our validation
to just say English words includes the words given.
The line break over here, I've run our test, we're passing.
Now we are emitting a warning
If you happen to provide a word of the day
that doesn't exist in the list of English words
that we have in that json file.
Perfect. So we ran our tests.
We saw that everything was passing.
Let's make a commit.
Enforce that the word of the day is a real English word.
Well, now we're back to our refactor phase,
because our json file is composed of five letter english words,
that are in uppercase.
Our first two validation rules are already built into it.
Therefore, they are redundant.
I should be able to simplify our validator
to just check to see if the word given exists within the English word
from that json file.
And if we run our tests,
you can see that we didn't add any regressions
by simplifying our validator.
So let's make a commit. This could just be simplify validation.
Okay, we are almost done.
There is one more task that I want us to write.
And it's effectively that if you provide a word of the day
that respects all the previous rules, you should not see anyone is showing up.
So let's just write it in here.
test, no warning is immediate if the word of the day provided
is a real uppercase English word with five characters.
All right. So I'm going to copy everything that we have in here,
Paste it in.
And let's just provide tasks.
And now we want to search that it was not called.
And you can see that we are already passing because of our validator.
With that said, this test is still pretty valuable
because it enforces one very important guideline for our app.
The application will not be rendering warnings.
If the game is instantiated with a valid word of the day.
So I want to keep this test around.
Let's commit this.
And a good commit message in this case, could be,
ensure no warnings are rendered when a proper word of the day is provided.
That was great.
In this lesson, we covered the usage of spies and mocks
to investigate if specific functions are being executed.
And we also covered how we can enforce
rules for our vue component props through validators.