Narrator: In the last section,
we finished writing our first test
by putting it in a describe, an it, and an expect statement.
We then ran it at the terminal
with the command NPM run test: watch
and we saw some output automatically pop up here.
It said app and it showed a checkbox
and we saw a text that said shows the correct text.
So the output that we have right here
is the report that I was mentioning earlier.
It's the report of all the specs that ran.
And it also shows which tests ran.
And if anywhere failing it would show which ones failed.
And so now you can see the purpose
of the text that we put on the describe
and the it blocks.
With the describe we had app
and with it we had shows the correct text.
And so you can very plainly see what the source
of that text is from now.
So if we wanted to,
again, we can make this text anything we want
it just needs to be something kind of reasonably clear
so that if a spec fails and it said,
you know say, "App shows the correct text was failing",
we would wanna have a reasonable idea
of where in our spec file that was occurring
and we would wanna have a reasonable idea
of exactly what logic was failing as well.
So again, that string is just to help us
with the reporting side.
Let's see what happens when we make our spec fail.
So there's two ways that we can make a spec fail.
We can either change the assertion
so we can expect some different text
to be contained by our component,
or we can flip over to the component itself
and change the text here.
Let's try each way really quickly just to see what happens.
So in the first case,
let's change simple to, how about complex.
React, complex starter instead.
So I'm gonna save this,
and then over my terminal you'll see that
my tests automatically rerun
and they say very clearly,
"Well, app is has red text, the spec was failing.
One of our specs failed out of only one spec that we had."
And then most helpfully we also got an assertion error
about exactly what the failure was about.
So, the assertion error expected some object right here.
Who knows what it is really going on?
To contain react simple starter.
So the text that we see here helps us
narrow down what the failure was caused by.
Let's change this back to react simple starter and save it.
Our specs automatically rerun and they're now green.
Let's try going over to app test.
And then on this side, I'm just gonna delete simple.
So let's expect our component to contain the exact
string react starter.
I'm gonna save and we're back into a failing state again.
We expected our component to contain react starter.
Let's go back to simple and we're green again.
So what's really fantastic about this kind of live reloading
or live running of our specs is we can just
be over in our code editor, writing our code,
not really sweating what's going on,
and just save our document from time to time
as we're writing code.
And then our specs are going to automatically rerun.
They run very quickly.
As you can see, in this case it was just six milliseconds.
And so our specs rerun and we'll know,
"Hey, did we just break something
or is everything still working?
Are we fixing specs or are we breaking specs?"
So getting this instant feedback is very helpful
as we go through development.
Okay, so we've written out one very simple spec here.
We have at least a reasonable idea of what's going
on with describe, it, and expect.
We haven't really spoken about the import statements
at the top too much, but again,
we'll come back to those later on.
I think the best thing that we can do now
is figure out a feature that we can build
where we'll practice test driven development.
So we will plan out a feature, we'll write specs for it,
and then we'll go build the actual feature
and let the specs kind of guide the work that we're doing.
So let's go ahead and get started on that
in the next section.