Kaynağa Gözat

perf(test): run replay snapshot files in parallel

The snapshot config serialized all 13 files for every mode, but the
fixture-writing rationale only holds for record (real API quota per
scenario) and refresh (write-back harvests volatile values from
fixtures on disk). Replay — the keyless default and the CI mode — is
read-only with a unique temp dir per scenario subprocess, and the
suite factory already runs replay scenarios concurrently in-file.

Narrow the serialization to non-replay modes: pnpm test:snapshot drops
from ~49s to ~33s wall; record/refresh stay fully serial.
Turtle 2 ay önce
ebeveyn
işleme
ecdcc218b6
1 değiştirilmiş dosya ile 8 ekleme ve 4 silme
  1. 8 4
      vitest.snapshot.config.ts

+ 8 - 4
vitest.snapshot.config.ts

@@ -55,12 +55,16 @@ export default defineConfig({
       'packages/sdk/*/tests/**/*.snapshot.ts',
       'packages/ui/tui/tests/**/*.snapshot.ts',
     ],
-    // Each test boots a subprocess; give it room and keep the worker file singular. Replay tests
-    // opt into bounded in-file concurrency, while record/refresh stay serial because they write
-    // fixtures. The environment knob restores serial replay with value 1 on constrained machines.
+    // Each test boots a subprocess; give it room. Replay scenarios are
+    // read-only (unique temp dir and fixture set per subprocess), so replay
+    // runs the snapshot files in parallel and bounds in-file concurrency with
+    // the environment knob (value 1 restores serial replay on constrained
+    // machines). Record and refresh stay fully serial: record spends real API
+    // quota per scenario, and refresh write-back harvests volatile values from
+    // fixtures already on disk, so concurrent writers would corrupt goldens.
     testTimeout: 120_000,
     hookTimeout: 30_000,
-    fileParallelism: false,
+    fileParallelism: (process.env.DSH_SNAPSHOT || 'replay') === 'replay',
     maxConcurrency: snapshotMaxConcurrency,
   },
 })