Auth Registration Test

[00:00:00]
>> Speaker 1: Let's write some tests I know we have authentication, so we can totally do some authentication testing We also have habits, so we can do some habit testing

[00:00:00]
Oh yeah, those are the only ones I wrote anyway, so I guess I was already thinking ahead, so let's do that I'll probably still won't write all of these

[00:00:00]
It's a lot of tests; we'll just write a few of these for the sake of, well, also I didn't implement all the habit controllers so we couldn't test them all anyway

[00:00:00]
Let's get to it So what we're going to do is write some tests inside of, let's try some of the odd stuff, so we'll go and test

[00:00:00]
We'll say authentication Got our test here It just hit me that Vitest probably didn't find this test because it's like in a subfolder inside of tests

[00:00:00]
I'm still wondering why I didn't find it, but I'm thinking it's that I just set me up like it wanted me to fail I'm convinced that's what it was

[00:00:00]
We're going to import request from SuperTest SuperTest is the thing that will allow us to run our server without having to turn it on

[00:00:00]
We can programmatically drive our API through SuperTest as if it is a client but without having to expose a port and turn a server on

[00:00:00]
Because Express is just a framework, you can programmatically trigger the routes and the verbs without actually having to expose a port

[00:00:00]
SuperTest is going to do that for us We'll import our app, which is our server, and get our environment We don't have to import some things like `afterEach` because it's global

[00:00:00]
We'll import our test helpers to create test habit and clean up the database Let's try some tests We'll describe authentication endpoints

[00:00:00]
We want to test some basic endpoints After each test, we'll clean up the database, clearing all entries for habits, users, habit tags, and tags

[00:00:00]
These are test suites - placeholders for tests organized in a way After each is describing what happens after each test runs, not after each assertion, because one test can have several assertions

[00:00:00]
I want to describe a post request to `/api/auth/register` I'll write the test using the `it should` pattern, which clearly describes what we're testing: "Register a new user with valid data." I'll create a test user and make a programmatic request to our Express app

[00:00:00]
I'll create a fake user object with an email, username, and password I'll send this user data and set up assertions to check for: - A 201 successful post status - A response body with a user property - A response body with a token property - Ensuring the user object does not include a password When running the test, we encountered some validation errors that required tweaking the test setup

[00:00:00]
After resolving those, the test passed successfully This demonstrates the value of testing - catching potential issues early in the development process and ensuring our authentication endpoint works as expected.