Allow integration tests against the DB to be run in parallel

[mikealche]

Hi hi!

First of all thanks for this AMAZING framework. The idea to abstract away the API layer is brilliant.

Here's an idea that I had regarding testing:

Context

When doing integration tests that involve DB calls some issues may arise if the tests are run in parallel.

Example: In a test file you expect that a db.product.findMany() call returns and empty array, but another test file may have created a product just before you run that call.

This is not specific to blitz, but to any backend framework.
Most of the time the solution is to run the tests in series, however that may slow things down.

Idea

Let's make jest use a different schema for each file. In that way each test files that is run hit a different "db" (actually it will be hitting the same db, but with a different schema).

How?

In the server config of the blitz preset we could replace the current testEnvironment ("node") for a custom one. One that automatically creates a separate schema for each file on setup (and deletes it on teardown). Something like this

Notes

Each db schema will need to have the migrations run against it (since they will all be a new empty schema). However that takes a bit long (8 seconds in my computer for 8 tables approx).
In that case, we could provide two different cli commands for testing: one for running the server tests in parallel and one for running them in series.
(If the user chooses to run the tests in series, we should keep the "node" testEnvironment for the blitz server jest preset)

[flybayer]

Thanks @mikealche, this would be really nice. I'd love for someone to work on this. prisma-pg-jest looks nice except that it requires Docker, so it's probably not a good fit for a default setup. If Docker is required to really make this work, then I think it may be best as a recipe (like blitz install parallel-tests) and we can add docs for this.

What do you think?

[nickluger]

This is a great idea. I had a similar setup on a previous project. Docker is usually not needed, isolation provided by different, randomly named schemas is usually enough (for Postgres).

[nickluger]

Random named DB schemas, one created per test suite works for Postgres:

import { PrismaClient } from "@prisma/client";
import { sync } from "cross-spawn";
import { nanoid } from "nanoid/non-secure";
import which from "npm-which";

export function setupTestDatabase() {
  if (process.env.NODE_ENV === "production") {
    throw new Error(
      "You are trying to create a test database in a production environment. We think you probably didn't mean to do that."
    );
  }
  const schemaId = `test-${nanoid()}`;
  const url = generateDatabaseURL(schemaId);
  process.env.DATABASE_URL = url;
  const prismaBin = which(process.cwd()).sync("prisma");
  sync(prismaBin, ["db", "push", "--skip-generate"], {
    env: {
      ...process.env,
      DATABASE_URL: url,
    },
    stdio: "ignore",
  });
  return {
    schemaId,
    url,
  };
}

teardown

export async function teardownTestDatabase(prismaClient: PrismaClient, schemaId: string) {
  if (process.env.NODE_ENV === "production") {
    throw new Error(
      "You are trying to tear down a test database in a production environment. We think you probably didn't mean to do that."
    );
  }
  await prismaClient.$executeRawUnsafe(`DROP SCHEMA IF EXISTS "${schemaId}" CASCADE;`);
  await prismaClient.$disconnect();
}

lil helper

function generateDatabaseURL(schema: string) {
  if (!process.env.DATABASE_URL) {
    throw new Error("please provide a database url");
  }
  const url = new URL(process.env.DATABASE_URL);
  url.searchParams.append("schema", schema);
  return url.toString();
}