Instructor: In the last section,
we broke down this expectation right here
and spoke about every individual part of it.
In this section, we're going to get down to that part
that you're probably wondering why
I mentioned two sections ago.
I mentioned that this line of code is maybe not
the best approach to testing inside of our application.
So in this section, I'm gonna tell you why.
I can tell you exactly,
I'm gonna be as crystal clear as I can,
why this is not the best approach.
So one thing I wanna point out here is that at present
we are looking at this inner HTML property
and we're expecting to see the string comment box.
Now there's two things I want to point out.
Okay, two very important things.
I want to mention that we are inside of a test
for our app component.
That's the test file we're in right now.
We're looking at the test for our app component.
But if you open up our comment box file right here,
it's the comment box component that actually defines
that original string of comment box.
In other words, our app.test file
is trying to make an assertion
about the behavior of our comment box component.
We have a test file that is meant to look at one component
but it has some intricate knowledge or detailed knowledge
of how some completely unrelated file behaves.
So let's take a look at a diagram
and get a better sense of what's going on.
All right, here we go.
So this is a diagram of our app component right here.
Here's the app.test file, and you can see on here,
as well as our comment list, the comment box
and their respective test files as well.
So at present, our app test file right here
is essentially trying to make a proof
or trying to understand,
the secret internal workings of the comment box.
Our app.test file has special, privileged knowledge
of how the comment box component is working.
Now, that might not seem like the worst thing in the world
but let me show you something.
Let's say that I go over to my comment box file right now
and I change the text right here.
Maybe instead of comment box, we say,
box for comment, instead, and then I save this file,
and then I go back over to my terminal.
So when I go back over,
I'm gonna see that test is now failing.
So I made a change to the comment box component
and it caused a completely unrelated test file to break.
That might not seem like a big deal right now.
It might not seem
like it's the worst thing in the world to fix.
Of course you and I can very easily figure out
to go into our app.test file and update the text right here
to instead say, what was it?
Box for comment.
Save that and then if we go back over to the terminal,
we are working again.
So I know that right now it does not seem
like a complicated thing to fix,
but trust me, as soon as you working on larger projects,
you're signing yourself up for a real nightmare.
Because if you start working on some component,
like let's say, the comment box over here
and you start changing this thing's internal workings,
you start changing the text or you start changing callbacks
or class names or whatever else,
you're gonna start to see that maybe some other test
inside of your application starts to break.
And that starts to turn into a nightmare
because that means that you then have to open up
that other test file, you have to find the breaking test
and you have to understand
exactly what that test is trying to accomplish.
So rather than just working
on that nice little comment box file, rather than just
working on that solo component all by itself,
you now have to go to this completely unrelated component,
understand the tests around it
and somehow fix it up to behave the way you expect.
Now, again, in our example right here,
yeah, that test was really straightforward
but in a real, professional application,
the test logic inside this thing
might be far more complicated
and it will take you a non-zero amount of time
to read over that test
and try to understand what's going on.
So in general, when you and I start to write tests,
we try from one component not to access the inner workings
or the actual implementation details
of any other component, if possible.
There's certainly violations of this rule.
There's times where we really do need
to reach into that other component.
But this is a great example of where you and I
really don't want to know
about the actual implementation of the comment box.
We don't want to know
about the contents of its render method.
We don't want to know
about the text that's contained inside of it.
Instead, we want to try to write tests
that only have knowledge of the other component in general.
So it's not okay to have the app.test
be aware of the comment box's secret inner workings
but it is okay for the app.test to know that say,
the comment box component just exists,
or something like the comment list component just exists.
It's totally fine to say, hey, here's the app component.
It knows that this other component
in our application exists.
That's totally fine, no issue with that whatsoever.
So ideally, we would somehow fix our current test
by making sure that our app.test file does not know
that the comment box renders out the string comment box.
Instead, we would ideally just say that the app.test file
has knowledge that the overall comment box component exists.
That would be much more ideal
because then if we start to change the comment box,
if we start to change its internal workings,
no issue with that whatsoever.
Okay, so that's a quick example
of why we try to avoid writing tests like this right here,
where we are giving one component test file
intimate knowledge of the inner workings
of another component.
So let's take a quick pause right here.
We're gonna come back to the next section
and we're gonna start to examine this line of code
and figure out how we can fix it or how we can change it
to make sure that our app.test file no longer really has
a good idea of what's going on inside the comment box.
So quick break and I'll see you in just a minute.