Anatomy of a Test

[00:00:00]
>> Steve Kinney: In our example app, we have this little scratch pad here. Also on the website, there's a way to just open it in your browser to play around with it as well for this particular one. But this is that test that we saw in the very beginning, right?

[00:00:12]
And I need to just go into that directory. So I'll go into examples, scratchpad in this case. We've got this test, but having a test in an editor is great and wonderful, but we probably need to run it. And so we're gonna do npm test. And yay, it passes, which is what we expect.

[00:00:30]
So what does npm test come from, all right? In our package.json, there is the set called scripts, where our npm test runs vitest, which I will try my hardest all day to pronounce as V test, cuz I didn't realize it's vi, cool, cool, cool. Because this doesn't really have a real app.

[00:00:50]
The start script is to open up the vitest UI, which every time I set up a new repository I think I'm going to use, most often I don't, I just use the command line. But so that's where the npm test comes from. So if you make a brand new package.json, a lot of times you do like npm init, test will be echo.

[00:01:09]
You have no test set up, right? So usually you need to install some kind of test runner, just vitest, what have you. Whichever one's your favorite or came with your framework is good. And then you just make the test script that command that you would like to run.

[00:01:24]
You can see, once we start it, it just kind of sits there and waits. And what it's gonna do is rerun the tests whenever the code changes. And most of the modern test runners are also pretty great, cuz they will usually only rerun the tests of the files that you have changed, right?

[00:01:45]
Cuz if you have not changed the code, and it's not related to code that you've changed, there's no point rerunning those tests, because all of that takes time. The quicker you can get that feedback, the better. So we've got a skipped test here that we'll look at later.

[00:01:59]
But for the most part, we've got one passed. Everything's good. So here we've got that simple test. Now, what does it mean to fail? I mean, [LAUGH] something I know super well, but more practically in this moment, which is if those expectations are not true. So here we'll go ahead and we'll save it.

[00:02:18]
As you see now, my test fails, and everything is red and sad, right? So you get that visual feedback of when the world is not behaving the way that you expect, true? It passes, yay. But the tricky part that I wanna call out early is, various points, I've numbered these rules, but as I add more rules inside the ordering has changed.

[00:02:43]
One of my rules of programming or testing is, if your test passes, it doesn't mean your code works. It just means that your test didn't fail, right? So a passing test does not mean your code works, and this is where you can have 100% code coverage and bad tests simultaneously.

[00:03:03]
Just because your test passed does not mean your code works, it just means your code doesn't not work. And so let's talk about what I mean by that, which is, let's say I just commented out this line. My test passes. Do you know why it passed? Cuz it didn't fail, right?

[00:03:20]
The act of not failing causes it to pass. For example, really, all a failing test is, we've got this expect and to be true and that seems like some wild syntax. All it really does is it takes this, and then when it gets the other part of it, compares them, and if it's wrong, it throws an error, right?

[00:03:43]
And the act of throwing the exception causes the test to fail. So for instance, if I did this and I said, throw new error.
>> Steve Kinney: All right, my tests fail and you can kind of see that this is where it failed, because there's an error. Now it's not particularly good reason, because I just threw an error randomly, but that is what causes a test to fail.

[00:04:09]
It is simply going to run your function, right? You can make some assertions or expectations about what you expect to come out the other end, and if that is not true, it will throw an error, and that will cause your test to fail. But like I said before, not having expectation or subtle things like everyone's favorite part about writing Javascript is asynchronous code, right?

[00:04:30]
We love how easy asynchrony makes it, right? And so for instance, if we did something like this, we said setTimeout, and we'll put a little function in here, and we'll say, expect true to be false, or false to be true, depending on your feelings about life. And we'll say, do that in a second, my test passes, right?

[00:04:53]
Because the test completed before I made any assumptions about the world. And so you can see a world where you can still get yourself into a little bit of trouble. Towards the end, we will literally come back and revisit this and see, like, if you did need to wait a second to make an expectation, how you might solve that, we're not gonna go down that rabbit hole just yet.

[00:05:14]
That is a rabbit hole that we will walk by for now and then circle back to and then go down it later. But the important part here is, effectively, all your tests do is call a function, take the result. A unit test, on a very basic level, calls a function, looks at result, throws an error if it's not what it's supposed to be, moves on with its life if it does.

[00:05:35]
If any errors are thrown, test suite turns red and sad, right? That is, at the end of the day, all there is to testing.