-: In the last section
we put together our first test right here. In this section,
we're gonna talk a little bit about that line
of code and we're gonna pull it apart piece by piece.
We'll then continue by talking about why this line of code
that we wrote in particular is maybe not the best approach
to testing inside React app.
But we'll get to that in just a moment.
First, we're gonna pull that line of code apart.
Okay, So this is a diagram
of that line of code, and like I said
we're gonna understand every piece of syntax along the way.
The entire line of code by itself.
So like this entire line right here
forms what we refer to as an expectation.
Expectations are the absolute core
of the tests that you and I are going to write.
They form the lines of code
or kind of the proof that our code
or our application is working the way we expect.
Every it statement that you
and I put together can contain zero to a ton
like you know, functionally, dozens if we want to,
expectations. In general, you'll most frequently see one
or two expectations inside of a single IT statement.
Every expectation leads off with the expect function
and you can think of that expect function right there
as being somewhat similar in nature
to the IT statement that we spoke about a little bit ago
only in the sense that it is a globally available function
that we do not have to import or require into our test file.
So we can just write out, expect, and we're good to go.
No imports required.
The first argument
to the expect function is going to be the object
or the property or the array or whatever it is inside
of our application that we're trying to inspect.
So it's the thing that we're trying to look at
improve some fact about.
In this case, we wanted to inspect the HTML contained
by that div element.
So that is the subject of this expectation.
It's a thing that we're trying to look
at and prove some fact about.
After we list that out, we then write a matcher statement.
The matcher statement's purpose is to kind of
clarify what property or how we are trying to
inspect that thing that we passed in over here.
So in this case, you can kind of read this matcher.
So this is the matcher as simple English.
We are saying that we expect this HTML block right
here to contain the string, comment box.
So the matcher is going to modify exactly how
our expectation behaves.
Then the last piece of every expectation is going to
be the value that we expect to see.
We don't always have an argument over here
after the matcher.
There are some matchers that do not expect to
receive an argument at all.
For example, we could have replaced to contain right here
with a matcher of to equal, or excuse me, not too equal
but to be truthy.
So the to be truthy matcher does not expect to
receive an argument
and instead it's just gonna check to see if
div.innerHTML right here is true or false.
So this would be an example
of a matcher that does not require an argument
but in our case, we're using to contain.
And that one definitely does require an argument.
And the last piece right here
the comment box just spoke about it.
It's essentially what we want our value to be.
So we want our innerHTML right here to contain this value.
So we are always gonna put our ideal case over
here on the left hand side is gonna be the thing
we're inspecting. Over here is our ideal case
or the thing that we want it to be.
Okay. So that is expectations in a nutshell.
We're gonna end up writing
out a ton of expectations throughout this first application.
So we'll talk about expectations
as we go along a little bit more.
But before we take care of that
I want to talk a little bit about why this expectation
that we just wrote is maybe not the best approach
for what we're trying to prove here
for trying to prove that our div contains the comment box.
So let's take a quick pause, we'll come back
to the next section and we'll talk
about how we could improve this line of code
and more importantly, what's wrong with it right now.
So quick break and I'll see you in just a minute.