Running Tests in Go

[00:00:00]
>> Melkey: This is going to be us creating the func test create workout and in this case, we'd actually go ahead and run it and test it out. So if you go back and make sure your database is running, especially workoutDB_test, if you chose to separate it or not.

[00:00:18]
And there's a few different ways you can do this. I recommend go cd into internal, cd into store. All right, if you do an ls, you should see workout_store_test.go, all right? And if you run go test,
>> Melkey: Relation, let's see, truncating was workout and tires, classic. I knew I was gonna do this one time.

[00:00:44]
I have a mistake here, workout entries. I even said it think yesterday that I always type it as entires. Workout entries, okay. If you run it now, go test, it passes. So there's a few things we're gonna go back and to see what is really happening. So first, to run a test, there's actually built in test command in Go, so go test.

[00:01:07]
And then we use this indicator to test everything in this directory that we are in that you can, right? And so it goes to the test you can see in the failure, it's a bit more explicit that on the failure, you can see very similar to when we ran our Docker compose the first time.

[00:01:23]
It's migrating the user's workout and workout entries as I wanted it to. For every test suite, I want this to be like a new fresh db that we can check and validate. And then you can see in what function test create workout, we got this error. It tells me where the error is with the line right here and what the error was itself.

[00:01:43]
So here I had a typo in workout entries, all right? And then we ran go test and we see, okay, this means all the tests pass, but what does it look like if the tests don't pass, right? So if you go here back to something like this, right?

[00:02:00]
So let's say instead of false for the valid workout, for some reason, do we want an error? Okay, so if I go back and run the exact same command, go test, you should see here, right, the name of where it is. So test, create workout, valid workout, which is the name of our tests, and it's the error trace, right?

[00:02:21]
So it gives me exactly where it is, line 97 in what file, and an error is expected, but got nil, okay? And so we error out on our test suite. So that's kind of how it looks if you have passing tests and then test that fail. So the stack trace does a pretty good job of explaining or giving you all the information you need to kind of debug and see what's going on.

[00:02:54]
Does anyone have any questions in terms of the testing tables, the testing fixture. Why I wrote this test the way I did? Is kind of making sense?
>> Speaker 2: I have a more like general question.
>> Melkey: Yeah.
>> Speaker 2: Is it pretty standard practice to co-locate tests with the files that they're testing?

[00:03:16]
>> Melkey: Yeah, so I kind of put that into a project structure umbrella question. For me, I like to co-locate if I have the workout store, I like to have the test right there. I know some people like to do a test folder within a package, that's fine, it's up to you.

[00:03:40]
But remember, if you have your test outside the package, pulling stuff like the store can be pretty difficult. Right here, we have our ability to get call of these because we don't have to import anything, right? New Postgres Workout store exists in the same package, which makes it super easy for me to not even have to worry about these imports, right?

[00:03:59]
But as most of the answers always go, it depends on what you want. This is kind of my style, this is what I'm used to for testing stuff.
>> Speaker 3: Is there a command that parses the whole project and runs all the tests.
>> Melkey: Yeah, like all in one, yep.

[00:04:22]
So instead of going, into a folder, folder, folder, folder, folder, you can go all the way back up to the root here. So I'm at the root, you can run go test and the amount of folders you want this to dive deep into. So remember, in the other one the command, this is gonna be kind of hard to demonstrate, but the command was just go tests, and then the single dot, because we were already in the section of where we want our test to be.

[00:04:48]
Here because we went out a few directories above and we're at the root, we have to tell go, how many layers deep do we want to fully run all the tests? And you can see here we have node test files, API, app, routes, utils, no test file. It finds one in internal store, it's like, this is cached, I don't need to do anything.

[00:05:06]
You didn't change it in your test file, it's the same result. But that's the command. So I am not gonna continue running tests in this file, just for a few reasons. One is time and one is like, it gets pretty repetitive. I do want to kind of emphasize, I'll take this opportunity to discuss again the approach of the style of the test, right?

[00:05:28]
So I think table test is something, it's fairly obvious. It's just a slice that we iterate over, like there's no magic there. But when you do want to create your own test, especially data store tests. My recommendation is to really test the shit out of it. And excuse my language, but here we're creating the workout, that's good.

[00:05:52]
We're validating this, but I also took it one step further, and retrieving it. So not only am I doing a write request to this test db. I'm also getting it back and validating, right? So I'm kind of really exercising the fact that it's like a db that we can use.

[00:06:08]
So go ahead and fully test it. What do you expect this to work, right? If you're manually testing and this actually helps, right? Now, if I were to add a new end path, or another file, excuse me in, that was weird. Here, instead of manually testing it, going back, okay, it's here, okay, let me go back.

[00:06:27]
Let me create the curl, okay, I can just create a test for it now, super easy and check if it works or not. So there's some advantages to testing for sure. And again, this is just kind of my style of testing, especially for database layers.
>> Speaker 2: Someone just mentioned that the repetition of testing is nothing compared to writing error not equal to nil.

[00:06:50]
>> Melkey: [LAUGH] Tell them they are right.