Testing with Vitest

[00:00:00]
>> Speaker 1: All right, so for Testing Let's get to it This next one is mostly about going through all the necessary things we need to start writing tests There's some setup we need to do, so I'll talk about that and the philosophy behind it As I mentioned earlier in the course, you're going to be using Vitest, which I think is the best testing framework out there

[00:00:00]
I have a little chart here based on my experience using all these tools, and Vitest is just the best in my opinion I couldn't even get Jest to work on ESM modules and TypeScript—it just would not work So we're going to use Vitest I think it's great, and if anybody has other opinions about testing tools, I'm happy to hear them

[00:00:00]
The first thing we need to do before running tests is create a different database to test in We don't want to test our code against a database we're using for other reasons We don't want to test against a development database that we've spent so much time seeding and working with because the test database is going to dirty that state

[00:00:00]
It's a good reason to have a separate test database We'll probably make another database I'll go to neon.new, click try in the browser, verify I'm human, get my new database URL, and go back to my app If I don't already have a .env.test file, I'll make one in the root of the project

[00:00:00]
I'll just copy the database URL, and there we go DATABASE_URL is set Next, we need to set up some configuration First is the Vitest config.ts This might already be in the repo, but I've included it just in case you want to reference it later Most of this configuration is automatically set up by the Vitest CLI, so you don't really need to know how to write it from scratch

[00:00:00]
Essentially, this configures how Vitest is set up I'm defining the test environment with `global: true` Most JavaScript testing suites have functions like `describe`, `beforeAll`, `test`, etc By setting `global` to true, these functions are added to the global space, so you don't have to import them in every test file

[00:00:00]
Global setup runs files before any tests Clear marks or store mocks automatically clean up mocks before and after each test runs This is important because if you don't reset a mock, and the next test expects something different, you're creating dependencies across tests

[00:00:00]
Your tests should be stateless—you should be able to run any individual test independently and have it behave the same way The `pool` setting runs tests sequentially to avoid database conflicts By default, Vitest runs tests in parallel, which can be fast but problematic

[00:00:00]
If multiple tests try to insert a user with the same email simultaneously, you'll encounter constraint issues or inconsistent test results Running tests sequentially (single-threaded) prevents these problems No plugins are needed—it works out of the box.