Narrator: In the last section,
we went over the testing report that MOCA gave us
from the command line.
We saw that we had a single spec app that contained
or, excuse me, a single describe of app
that contained one spec, just "shows the correct text".
And we also saw what it looked like when it failed as well.
We also saw that these specs automatically rerun
whenever we change a file inside of our project,
which is really, really handy.
So the next step to move forward
in learning a lot more about testing
is to build an actual feature and build it
with a kind of test driven development approach
where we're gonna first write our specs out,
and then we're gonna write our component
and watch the specs go green or pass over time.
So let's talk a little bit more
about the feature that we're gonna build.
I'm gonna pull a mock-up onto the screen,
and I know it's a little bit blurry.
I took a screenshot of this one, very small
but hopefully it's legible right here.
So we're gonna be building a comment box of sorts.
This section is a lot more about testing
and not necessarily about
super interesting react components.
And so my goal here was to make a simple react component
that we can reasonably just learn about testing right now
as opposed to have to worry about
some really crazy new feature or something like that.
So the goal was to have a fairly simple application
that we were putting together
and focus a lot more on the testing side.
Let's look at the comment box a little bit.
The comment box is gonna have at the top some text
that just says, "Add a comment,"
or, you know, something similar.
It'll have a text area where a user can enter some text
and then a button to just submit the, the comment.
When a user submits a comment,
it will be appended onto a list underneath the comment box.
We're not going to use Ajax
or anything like that to save these requests.
Again, our goal is just to
test react components in this exercise.
So we're going to hold these comments in local state
in a redux store, and not worry too much
about saving them to a server or anything like that.
We can worry about that stuff later
when we've got a better idea
of how to write specs in the first place.
We'll take things one step at a time.
Okay, so this is more
or less the feature we're gonna build right here.
Pretty straightforward.
Let's do a little bit of thinking about,
you know, how are we gonna put this thing together
with different react components?
And as we're writing tests
what do we really want to test at all, right?
That's the goal here.
We gotta figure out what we want to test.
I'm gonna pull another mock-up onto the screen.
Here we go.
So this one is much better sized.
So I'm gonna suggest that we are going to separate
our feature into two separate components.
The kind of yellow,
I dunno, I guess that's yellowish,
component on the top and the blue one on the bottom.
So the yellow one on the top will call a comment box
or a comment adder,
or something to just indicate we use this component
right here to add comments.
Then we'll have a separate component
which we'll call a comment list.
It's the blue one here at the bottom.
That's just responsible for showing a list of posts.
And so before we ever do test driven development
before we ever start putting pen to paper
and write any code or any test like that,
we have to always ask ourselves first,
"What do we care about when we're writing tests?"
What do we wanna write a test about?
What do we wanna make sure that
when another developer comes through here
and starts fiddling with some code?
What do we wanna make sure that we are testing
to make sure that they're not breaking anything?
So I've put a couple of ideas over here
on the right hand side.
If you have other ideas, totally fine,
we can, you know, try wiring those in over time,
but we'll start with these simple assertions
on the right hand side.
So on the top level component, the comment box,
we really care about the fact
that it has a text area and a button.
And we also care about when we enter some text
into the input right here, we should see the text
like actually input on the screen, right?
Actually update on the text area.
And that's gonna be really relevant since
we're gonna end up making this into a controlled input.
If you're not familiar with controlled inputs
and react, no problem, we'll go over it.
But basically the tests
that we're going to be writing here.
It's just gonna make sure
that our controlled component is behaving appropriately.
For the component list at the bottom,
what we really care about is that
for any comment that we provide to the comment list,
it should show one LI.
And we also care that
if we hand it multiple comments, so let's say three,
we should see multiple LI's, and we should see
the text for each comment within the component.
And so the approach that we're taking here
of these type of specs that we're writing
is approach that I personally am a tremendous fan of.
Let's think about this approach for a second.
If we only care about writing tests that say, you know,
we show a comment in an LI
and given a list of comments that shows all the text,
that means that if another developer comes through our code
and they start changing the format significantly, right?
They might rename some methods
or they might turn the component
from a class based component
to a functional component or any number of things.
The way that we write our specs is just going to assert
that the end product, right, the end product
which is the HTML that gets put on the screen
is gonna be rendered correctly.
And so I'm a huge fan
of writing tests where we make assertions
about the end product,
about the HTML that ends up on the screen
and not so much about our components
say having a very specific method
that when we call that method something happens.
I want to make sure that my tests
allow other developers to refactor my code
as much as possible. I want my test to be flexible, right?
And only when a feature starts to break
do I want to see them fail.
So you might find other tutorials online
other guides where they say,
"Oh yeah we need to do like unit testing.
We need to test individual methods on our component."
And I just don't think that's the right approach.
And I really think that once we start writing some specs,
you're gonna agree with me as well.
So let's go ahead in the next section,
start putting this component together along with its specs.
I'll see you there.