Set up integration test setup only once

[kevcodez]

Hi there,

I was wondering if it's possible to do a global setup for integration tests ONCE only. I've struggled to do this with Jest, as it seems super unreliable to do so.

What I would like to achieve:

Separate unit and integration tests (already done so by giving it a different file name pattern), run the unit tests just as they come, but for the integration tests, run the setup (starting in-memory Mongo, Redis, ...) only once and share the setup and eventually have a global teardown method taking care of the teardown afterwards.

In jest, this is supposed to be possible with testEnvironments, but they never worked for me, so I was wondering whether Vitest supports a similar approach that would enable a one-time setup/teardown (not per file, but for the entire test suite).

[danielhra]

Did you find a way to achieve this?

[kevcodez]

Still stuck on Jest and suffering in silence

[AriPerkkio]

I was wondering whether Vitest supports a similar approach that would enable a one-time setup/teardown (not per file, but for the entire test suite).

Sounds exactly like a use-case for globalSetup. Does that work for you?

[peacechen]

globalSetup doesn't run for each integration test file. globalSetup runs once for a project it is defined in. setupFiles run for every test file.

That may be the intent, but it runs for every test file. I have test suites in separate .test.ts files and this executes repeatedly, once for each test file:

export default <Environment>{
  name: "prisma",
  transformMode: "ssr",
  async setup() {
    const env = { ... };

    await execSync(
      "npx prisma db push --force-reset",
      { env },
    );

    return {
      async teardown() {
        // called after all tests with this env have been run
        await prisma.$disconnect();
      },
    };
  },
};

When run in parallel, every test tries to clear the db, causing the other tests to fail.

[sheremet-va]

This is not a global setup, this is a custom environment. Environments are created for every file unless isolation is disabled.

[CleytonGoncalves]

globalSetup indeed runs once per project. Is there a way to make it truly global? i.e., once per vitest execution, not just per project?

[AriPerkkio]

@CleytonGoncalves a custom reporter should be able to do that.

• https://vitest.dev/api/advanced/reporters.html

[peacechen]

@CleytonGoncalves a custom reporter should be able to do that.

• https://vitest.dev/api/advanced/reporters.html

Thanks for the work-around. Reporters look like they could be leveraged for lots of different uses. Semantically it isn't intuitive though. For someone looking in the documentation for a way to hook into a single global setup, I would never have thought to look at reporters.

[yudin-s]

Yes, globalSetup is the thing you want for this. It runs once before the test workers start, and the function it returns is used as teardown after the suite finishes.

For something like Mongo, I would keep it on a separate integration-test config or Vitest project so unit tests do not pay the startup cost:

// vitest.config.ts
import { defineConfig } from "vitest/config"

export default defineConfig({
  test: {
    include: ["**/*.integration.test.ts"],
    globalSetup: ["./test/global-setup.ts"],
  },
})

// test/global-setup.ts
import type { TestProject } from "vitest/node"

export default async function setup(project: TestProject) {
  const mongo = await startMongoSomehow()

  project.provide("mongoUri", mongo.uri)

  return async () => {
    await mongo.stop()
  }
}

declare module "vitest" {
  export interface ProvidedContext {
    mongoUri: string
  }
}

And in a test:

import { inject } from "vitest"

const mongoUri = inject("mongoUri")

I would avoid relying on plain globals here because setup runs outside the test file scope. project.provide() / inject() makes the handoff explicit.