Instructor: In the last section
we added another spec to app,
where we just expected app to be showing a correct child.
We made that assertion by finding an HTML element
that specifically had the class comment dash box,
again, this was a point where we were really testing
to make sure that the HTML that was generated was correct,
and not necessarily testing that the render method
returns an instance of a comment box component.
So, this is a pretty flexible spec,
and if people wanna change it out in the future,
or change out the implementation,
it's pretty darn easy to do.
Let's continue by working on our text area right here.
So, I'm gonna say that we're gonna add
in an additional requirement for our comment box here,
we're gonna say that when a user enters a comment
and then submits it, we should clear out
all the existing text inside of the text area as well.
Okay so, two steps here, user enters some text,
we need to handle that, and then when they submit it
we need to clear the text area out.
So let's go ahead and, first,
write some specs around this,
and then we'll do the implementation.
We'll do our two it blocks, so we'll say it,
shows text that is entered.
And again, you might be asking yourself,
well, why are we testing like,
just that a text area works the way that it should work?
And I'll show you exactly why we're gonna do that
in a minute.
The next test that we're gonna write is gonna be,
when submitted, clears the input.
And so, there's something I wanna kind of,
point your attention to here.
We have three specs up here, three existing ones,
that are kind of assertions about the general behavior,
or just, you know, very low level characteristics
of the component, and now we just wrote
an additional two specs that are very closely related,
and might even share some of the same setup.
So, whenever we have it statements
that are very closely related, and we wanna show
to someone who's reading this in the future,
or even ourselves, that, hey, these two specs
are very closely related, we have the ability
to nest another describe block in here,
so let's see what that might look like.
We're gonna say, describe, entering some text,
and then we'll put in our function call,
or our fat arrow function, excuse me,
and then we're going to cut and paste
the two it blocks inside of that.
So, functionally, there's no difference here whatsoever yet.
We have not changed how the tests are ran at all.
All we've done is we've said,
hey, the two specs that are about to follow here,
that are inside this describe,
are concerned with entering some text.
So now that we're saying specifically entering some text,
we can update the two its here.
So, instead of showing entering some text,
it shows text that is entered,
which is kind of a tongue twister of sorts.
We might just say, shows that text in the text area.
Again, the only reason that we're adding this
describe here, is just to indicate to other engineers
that these two specs are very closely related.
Okay, so let's think about the two expectations
we're gonna write for each of these.
In the first case, we want to say,
hey, when something gets entered here,
we wanna make sure that that text area
has the input that we care about,
and then, on the second case,
when a user submits this thing, the text gets cleared out.
So, we're definitely going to have to do some setup
that is common to both of these tests right here.
In both cases, we want to, somehow, render the component
and make sure that there's some default,
or dummy, text inside of there.
So, luckily, we've already set up a before each
at the top that's rendered the component for us.
So, even though the before each up here is outside
of this describe, before each is our additive in nature.
So, if we have a describe here and a before each up top,
this before each is still gonna run
before our it statement down here.
We can also add as many before each's as we want,
so we can add another before each inside of this describe,
like so, that will do some additional setup
for our component that is only gonna
be executed inside of this describe.
So let's, kinda, break this down a little bit,
'cause I know there's a lot of code on the screen,
and it's probably getting a little bit confusing.
Let's, kinda, think through the order of operations here.
When Mocha first loads this file,
it's gonna run everything inside of here,
it's gonna load up these specs,
kinda cue them up to be ran,
then, it's gonna say, okay, time to run the first it.
We'll run this before each, and then we'll run the it.
We'll run this before each, and we run the next it.
We run before each, and then the third one.
Now, here's where it gets a little interesting,
and I'm just gonna clap some code here.
Mocha then says, okay, it's time to run
the next nested block of its.
Mocha's gonna run the top before each,
the child before each, and then the it.
It'll then run the top before each,
the nested before each, and then the second it.
So, all of these before each's,
they, kind of, stack up, so to speak,
they, kind of, stack up over time,
and you can use successive before each's
to customize your component, or your testing setup
for each of your child specs here.
So, what we might do inside of this before each,
is add in some code to pre populate that text area,
or to just, kinda, stick some dummy text in there
where we know exactly what that text is.
So, I've already set up a helper
for doing this kind of initial setup for us,
and again, this is a place where,
we're gonna use this code for right now,
and later on, when we go over our test helper file,
we're gonna look at exactly how this works
behind the scenes, okay,
so this is a little bit of a leap of faith here,
but just bear with me for a little bit.
To do our initial setup,
We've already got an instance of component
because it was already initialized
in our existing before each.
So, in here, all we need to do
is inject some text into that text area,
so to make that happen,
we're gonna say component find the text area
that's being rendered by the component,
and simulate, and this is the part where
it starts getting really interesting, a change event,
and I want the event to carry the text, new comment.
Okay so, a little bit weird, but just bear with me.
This is actually probably a really good spot
to take a quick break.
Let's continue in the next section
where we'll walk through this line of code right here.