00:00 The first thing I'm going to do is go into our vtest-config, and we're going to add a global setup right here. So it should point to this file right here. There we go. Boom. Okay. So now, when our tests run, when they very first start,

00:18 they're going to run this file first. So what is this file? Well, let's go to global setup in our test directory. What we're going to do in here is we're going to create an export. So export const, a base database path, that's going to go to the testprisma-base.db.

00:35 So this is going to be our base database upon which we apply all of the migrations and everything. So let's bring that in from node path. Then we're also going to export a function called setup. This is part of the convention for vtest. So the file that you specify as

00:52 your global setup should export an async function called setup. What we're going to do in here is actually what we're doing in our DB setup. So we're going to take this and get rid of that, move that over to here, and let's bring in execu-command from execu.

01:10 It's going to be basically the same except we need to apply this not to whatever is set as the database URL, but we want to apply this to our base database URL. So right over here, we're going to say, there we go, database URL is file base database path,

01:29 and that should take care of that for us. We could say const database path and use the environment variable or set an environment variable there, but it really doesn't make much sense because this is the only thing we need it for. Great. So that takes care of that. Now, instead of running

01:48 the migration before all of our tests in every single test process, we can actually just import the base database path and copy it over. So let's say await FS extra copy file, and we're going to copy the base database path over to the database path,

02:06 that unique database that's for this particular test. So now we can get rid of that, get rid of that, and we're pretty much done. Let's just take a look at this. So when we run our tests, I have nrt as alias to npm run test, and I sometimes forget that's what I'm doing.

02:24 But here we go. So we can take a look at this. We have our base DB is created, our reset is successful, it's applied at the migrations, and then all of the different tests are running against that one. If I run it again, you'll notice it doesn't do the migrations, and that's because the global setup only runs once per test session.

02:43 So we run it over and over again, and this is running way faster than before. The level of confidence that we're getting from these tests, like the integration tests are just awesome. It is fantastic the amount of confidence we're getting from these tests that are running quite quickly against a real database. It's so great. No need to mock out

03:03 any silly database mocks or anything like that. Now, if we run this again, then we're going to get our migrations running. That may or may not be super annoying, and I'm just going to show you really quickly an easy way we can avoid that.

03:18 What I'm going to do is import FS-Extra from FS-Extra. Let's get rid of these. Then right here, we're going to say database exists and FS-Extra. If the path exists, then we'll do an early return.

03:36 That way, it'll run the test again, whatever. If we run NPM test now, you'll notice the database already exists, and so it didn't even bother. Even getting our tests up and running from the get-go will be faster as well, which is quite nice.

03:54 There you go. In review, what we did here was we created a config in VTest to say global setup points to our global setup file. The global setup file exports a setup function, and that setup function is responsible for setting things up before starting the test session.

04:12 We're going to create this base database path, pointing to where our base DB file will be. We keep that file around. We don't delete it because it is get ignored anyway. If you wanted to delete it, you can return a cleanup function here and you could delete that there. That will run when the test session is all finished.

04:32 But yeah, I'm fine keeping it around, just get ignore that. In our setup, if the database path for the base database is already created, then we don't bother creating it again. Otherwise, we're going to run Prisma Migrate Reset with that as the database URL.

04:51 Then for our DB setup, instead of doing the migration for every single one of our processes, we simply copy the file over and we're done. You can still observe the test databases that are created when we run these tests. If I run the test again, you can take a look at this and maybe it ran too fast. But if you're watching carefully,

05:11 you'll see those databases getting created and everything. They are still getting created, still getting deleted. All of that stuff is working exactly as it was before. But now, we don't have to do that in every single test. We don't have to do the migration and everything. It's awesome. We can have real tests that run against real databases that run

05:29 real fast and give us real confidence. Real good job. See you.