Writing Your First Test

[00:00:00]
>> Steve Kinney: So let's go ahead and we're gonna switch to a different example. We're gonna go into this one over here called arithmetic. And it's got some real, don't worry, my liberal arts majors, you're gonna be okay. The folder is called basic math, the file is called arithmetic. So I'm just gonna open that up in this terminal over here.

[00:00:22]
And right now, there is not a lot going on in here. These are my very important functions. As you can tell right now, they don't do anything, right? And here are my wonderful tests. They don't do anything either, right? One thing you might notice is if you had no tests in this file whatsoever, right?

[00:00:47]
So if I go ahead and I just comment this all out, depending on the test runner, it will get somewhat mad at you. So I did a test right now. It's mad at me because there are no tests in there at all, right? One thing you can do is, for a given test or a group of tests, which we'll use to describe, you can put a .todo or .skip on it, right?

[00:01:10]
They effectively accomplish the same thing with two different meetings for you, the human, reading it later, which is skipping cuz this one broke and I don't know how to fix it, right? To do is, I'm totally gonna write these later, which is useful for when you're trying to start out, but also if you're making a boilerplate setup for people as well.

[00:01:32]
So I've got this running now. I can save this file again. Everything's great because they are intentionally skipped. And now, things are bad, and so a lot of times when we're doing this thing called test driven development, there's this process called red, green, and then refactor, maybe, depending on it.

[00:01:52]
It's really hard to refactor an add function, but generally speaking, start out with some kind of failure state, get it to turn green, and then do the next thing, right? Now, these, again, are gonna be relatively simple functions because I promised you we'd start out easy before I started slowly turning the heat up on you, but we can start here.

[00:02:12]
And so we'll say, import add from arithmetic.js, I gotta do a dot slash there. So this is, again, one of those key things is we've got this test file. Now the way the test runner works is it's basically looking for anything with .test.js or .test.ts, I think you can put stuff in, like an __test directory, but I don't do that.

[00:02:40]
Cuz I don't like my tests and my files far away from each other, cuz I'm lazy. If you do, you can do other stuff. For me, I want them next to each other because I probably wanna open them around the same time. So we have the test file, and that will then pull in our whatever we want to test.

[00:03:01]
And this is important, because if you're like, well, I can't pull that in because it makes 17 API requests. It's wrapped in React's Context API and seven other things. We'll talk about it. But the goal is to try to get yourself to these points where you can just pull in one function and test it out.

[00:03:16]
Because we talked about this before, there's ways to point the browser at the app. And that's good and you should do that. We'll talk about that towards the end. But those tests, to spin up a browser, to navigate to a page, to wait for it to load, to then go navigate the DOM to go see if stuff is in there.

[00:03:31]
Those are amazing tests because you know that everything works together, they're slow. And sometimes when you are writing code, that feedback loop of the quicker you can get, I see red, I see green, right, you can make more decisions a lot faster too. So they all have a time and a place.

[00:03:44]
I'm not gonna tell you how much of this one, how much of that one, because again, the goal is lowering the dread. Whatever you need to do to lower the dread, we'll talk about the use cases for each later, but these are fast, these are good if you can do it.

[00:03:57]
So then we can say, okay, what is it about adding? It should add two positive numbers.
>> Steve Kinney: Great, and we only put these names cuz we'll see it in this little chart over here while, and to see which one is failing. And so now we can say, expect, add, and we say 2+2 to be 4, and it's red.

[00:04:26]
Why is it red? Because 2+2 is not 4, 2+2 is undefined. And again, this is the rhythm of this test driven development thing you've heard so much about, which is, okay, it's red because a function doesn't do anything, right? So we can go ahead and handle that. We say a,b, we'll just have a return a+b, and now it's green, and that feels good, and I get a little bit dopamine, and life is good.

[00:04:57]
And then theoretically, the next stage would be that refactor, now that you have something passing, you can go ahead and begin to refactor and clean up the code. The goal is to get an implementation that works. And now, as you go to refactor it, and again, there's not a lot to refactor here.

[00:05:17]
But on a more complicated version, right? You can begin to refactor it, knowing that every time you hit the Save button, you're gonna get feedback of whether or not you broke it.