Fixture startup time is included in the first test which asks for it.

[alexmherrmann]

Describe the bug

I have a fixture defined in my file which does quite a bit. It starts a database with testcontainers, migrates, and seeds the database. It does this in the "worker" scope. With the 2 workers I have configured it to use, according to the logs it is correctly setting up just the two, and over several files, it keeps those alive before finally shutting them down. This is the fixture I have made:

	testContainerRuntime: [
		async ({}, use) => {
			// Create runtime once per worker
			const runtime = ManagedRuntime.make(AllMockLive);

			// Warm up the database
			const result = await runtime.runPromise(withDb((db) => db.select({ one: sql`1` }).from(interactions)));
			console.log("warm up resulted in", result[0].one);

			// Provide the runtime to all tests in this file
			await use(runtime);

			// Cleanup when all tests in file complete
			await runtime.dispose();
		},
		{ scope: "worker", auto: true },
	],

The "warm up" is there to make sure that the database is actually started and is responding. The problem I am having is that unlike the cleanup, everything before the use is being counted as time for the test which first uses it. Meaning that aggresive timeouts of 2-3 seconds simply don't work, because whatever test is run first will include all of the container set up time. You can see in the screenshot that 5433/5542 of the milliseconds it claims the test file has run for is just on whatever test is run first from the file.

The impact is very minimal, begrudgingly increasing the timeout is all that is needed to keep them running, but I imagine the expected behavior is for it to exclude that time.

Reproduction

A super tiny one, just look at fixture.test.ts and pnpm install && pnpm vitest run to see the reproduction.
https://stackblitz.com/edit/stackblitz-starters-vdlbdnby?file=fixture.test.ts

System Info

System:
    OS: macOS 26.0.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 147.95 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.10.0 - /Users/alexherrmann/.local/share/mise/installs/node/24.10.0/bin/node
    npm: 11.6.1 - /Users/alexherrmann/.local/share/mise/installs/node/24.10.0/bin/npm
    pnpm: 10.17.0 - /Users/alexherrmann/.local/share/mise/installs/pnpm/10.25.0/pnpm
    Deno: 2.4.5 - /opt/homebrew/bin/deno
  Browsers:
    Chrome: 143.0.7499.111
    Firefox: 141.0
    Safari: 26.0.1
  npmPackages:
    playwright: ^1.57.0 => 1.57.0
    vitest: ^4.0.15 => 4.0.15

Used Package Manager

pnpm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[Ujjwaljain16]

Problem Description :

When using worker-scoped or file-scoped fixtures with expensive setup operations, the setup time is incorrectly included in the duration of the first test that triggers the fixture initialization. This makes aggressive timeouts impractical and provides misleading test duration metrics.

Observed Behavior:

In our reproduction test with a 2000ms worker-scoped fixture setup:

First test duration: ~2013ms (includes fixture setup)
Second test duration: ~2ms (actual test time)
Third test duration: ~1ms (actual test time)
Expected Behavior
The fixture setup time should be tracked separately and not included in any individual test's duration. All three tests should show similar durations (~1-2ms).

Root Cause Analysis

Current Test Timing Flow in

Line 286: const start = now() - Timer starts
Lines 288-293: Test result initialization
Line 314-320: beforeEach hooks (including fixture resolution via 
withFixtures
)
Lines 322-333: Actual test function execution
Line 441: test.result.duration = now() - start - Duration calculated

The issue is that start is set before fixture resolution begins. When a worker/file-scoped fixture is initialized for the first time, the setup happens during step 3 (in beforeEach hooks through with Fixtures) but the timer has already started in step 1

Fixture Resolution Flow in

Lines 135-200: 
withFixtures
 function wraps test/hook functions
Lines 175-197: 
resolveFixtures
 async function sets up pending fixtures
Lines 205-268: 
resolveFixtureValue

handles actual fixture initialization
For worker/file scoped fixtures, this is where expensive setup occurs
Once initialized, fixtures are cached and reused
The first test to request a worker/file-scoped fixture pays the full setup cost in its measured duration.

[Ujjwaljain16]

Heyyy
@hi-ogawa
I tried to fix this bug
Would request your review on the PR raised