Instructor: In the last section,
we made use of this new initialState prop
that we added to our root component
to get some data into our comment list.
So now the last thing we have to do
is write out an actual expectation inside this test.
So I'm gonna delete the console log
and I'll replace it with an expectation.
So we'll look at the wrapped variable right here.
So on wrapped, we're gonna try to find
every ally in this thing, and they'll look
at the length or the number of allies that were found.
So there should be two allies,
since we have two comments right here.
And so I will do a toEqual 2, like so.
All right, so I'll save this file.
I'll trust that this test is gonna run just fine.
For right now, I don't wanna have to flip over
and wait for it to run.
So for right now,
we'll just immediately get started on our next test.
So the next test that we want to work on is to make sure
that the text from each comment
is actually visible on the screen.
Now, it might look like these two tests
that we're putting together right now
are, like, very similar or even identical,
but I would argue that they both serve
a slightly different purpose.
So the goal to first test is to make sure
that exactly one ally shows up per comment.
This test right here is going to actually help to make sure
that we don't have a bug around our list rendering.
For example, we might accidentally have some big bug
inside of our application where we render out,
like, six allies per comment
that gets added to our Redux store.
So that's the goal of this test right here.
Within this test is to make sure that inside those allies
the correct text is actually showing up.
So I would kind of argue that they compliment each other,
do slightly different things.
Anyways, let's flip back over to our CommentList test,
and we'll start working on the second test.
So back over here, I'll add on a new it statement.
We'll say this, it shows the text for each comment.
I think that's reasonable.
So then inside of here, all we have to do
is looked at this old wrapped element right here,
inspect the HTML or the text that it produces
and verify that it contains the text,
Comment 1 and Comment 2.
That's pretty much it.
Now, way back at the start of this application,
we wrote a single test where we looked at the value
of some component or the text
or the HTML produced by a component,
and verified that in fact, yes,
some given text exists inside there.
But that was back before we were using enzyme.
You'll recall we were looking at a particular div
and getting all the HTML that was contained inside that div.
So now that we're using enzyme, we need to come up
with a slightly different way of handling this.
So let's go take a look at the enzyme documentation again,
and we'll get a better sense
of how we can kind of inspect this wrapped element
and find all the text that's in there.
All right, so I'll go back to my enzyme documentation.
Now, I'm gonna show you two different ways of doing this.
I'm gonna show two different ways
'cause there's definitely a very easy way to do it
that will work right away,
but enzyme kind of doesn't really recommend
you do it this way.
So underneath the section for Full DOM Rendering,
I will find the text method, which I have right here.
So we can call the text method on a wrapped element,
and it will return all the text
that is inside of that element.
Now, the reason I say
that enzyme doesn't really recommend this
is that if you look at the documentation
that says this function should be looked at with skepticism
if being used to test what the actual HTML output
of the component will be.
And they don't really say why.
I do not know why.
I'll be honest with you.
I don't know why they say look at this with skepticism.
So they say, if you're trying
to test the actual HTML output,
which is what you and I are trying to do,
then use the render function instead.
So if you want to, you can leave things easy breezy,
call the text method and say,
"Hey, within the text that comes out of this component,
we should find the strings Comment 1 and Comment 2."
But I'll show you the way that enzyme recommends you do it,
which is just a little bit more complicated.
So they say, use the render method instead.
So we will look at the render method.
So here's render right here.
So when you and I call render,
it returns something called a CheerioWrapper.
Well, that kind of begs the question,
what is a CheerioWrapper?
So Cheerio is a library very similar to jQuery.
It allows us to kind of crawl or run queries
or essentially selectors over snippets of HTML.
So if you want to,
you can very quickly pull up the documentation for Cheerio
by doing a Google search for cheerio js.
And I recommend adding the js on there
'cause otherwise, you'll find a breakfast cereal.
All right, so then we'll find the GitHub page right here.
And you'll see a couple of quick examples
on how to use this thing right on their GitHub page.
So on here, essentially, yep, it looks very similar
to how jQuery works, complete with the dollar sign.
Now you don't have to use the dollar sign.
It doesn't have any special meaning.
They just say like, "Hey, if you want to,
you can assign this thing to the dollar sign."
And then you can run selectors on it
and try to pull off different properties off that HTML.
So a really easy way of handling this,
is to take that CheerioWrapper
that gets returned from the render method
and calling exactly what you see on it right here,
the text method.
text, if you do not pass in any argument to it,
will return all the text that's contained
inside of the element that got selected.
So that's what we're going to do.
So I'm gonna flip back over to my code editor,
now that we've seen the long way of doing everything.
Let's again first get started with a simple console log.
So I'll do wrapped.render,
so that's gonna return my Cheerio element,
and then I'll call text on it.
And that should print out all the text
that is rendered by my component.
So after we get this printed out, we should be able
to do a very similar expect, blah, blah, blah
to contain Comment 1 and Comment 2.
So let's save this file, flip back over the terminal,
and see what actually gets console logged.
Right, so back over here.
Again, kinda longer on my test suite.
I apologize for that.
There we go.
So right here, you'll see our console log,
and we get back the very plain text
of Comment 1 and Comment 2.
So it's something to be aware of here
is that when we use that text method,
it returns the actual text that is contained
inside of that entire component,
and it does not return any of the actual HTML.
So when we use text, it's specifically to look
at the visible text that is returned by the component.
Okay, so we clearly get back Comment 1 and Comment 2,
which means back inside of our test,
I will clean up the console log
and we'll replace it with an actual expectation.
So I will say expect wrapped.render .text,
and we'll do the toContain matcher again.
And I will expect that to contain the string of Comment 1.
So Comment 1.
And then I will do the exact same thing a second time,
wrapped.render .text toContain Comment 2.
So I think you have a pretty reasonable idea
of what's going on here.
We cannot test for multiple toContains
inside of a single expectation.
That's why we did two separate toContains
or two separate expectations.
One's gonna specifically look for Comment 1
and the second one is specifically looking for Comment 2.
Now, I guess you could technically do something,
like Comment 2 like that
and combine it all into one expectation.
But yeah, probably not gonna want to do that.
All right, so we'll save this file,
we'll flip back over the terminal,
and it looks like all of our tests are good to go.
Awesome.
So that is the basics of testing with React and Redux,
the very basics.
So we've gone over testing list components,
calling action creators, testing action creators, reducers,
all that kinda good stuff.
But I think you'll agree with me
that while we've kind of, you know,
done a good overview of testing,
we haven't really seen a lot of super practical stuff.
So I want to add in one more function or one more piece
of functionality to my component here, my application.
So let's take a quick pause right here.
We'll come back the next section
and talk about exactly what we're going to add.