AVA's repository setup stopped before a test could run in our sandbox. The package-manager launcher rejected the declared pnpm specification. If you're considering AVA for a Node.js project, that is a concrete obstacle to reproducing this contributor checkout, while the runner's behavior in your application remains an unanswered question.
The README gives a different entry point for users: add AVA locally to your own project and configure its test script. Keep those two jobs separate. Our failed checkout preparation isn't evidence that a released AVA dependency cannot run your suite, and it supplies no performance comparison with another runner.
File isolation leaves shared resources for you to manage
AVA's writing guide says each test file runs in a new worker thread by default, with separate processes available as an alternative. Inside that model, tests run concurrently unless you choose serial execution. File isolation is useful when code carries process-local state, but it doesn't give every test its own external database or network service.
The distinction matters for a suite that mutates shared resources. A worker can isolate JavaScript state while another worker still reaches the same database record. Decide how each test owns its external data before treating concurrent execution as a benefit. That is an integration responsibility implied by the documented execution model, not a defect we observed.
The test.serial modifier only applies within a particular file. Other files can still run at the same time unless you use the suite-level serial CLI flag. A team migrating a suite that relies on execution order should account for that explicitly. Fixing one file's order does not settle the behavior of the rest of the suite.
What happened when we ran it
Our October 30, 2026 run at commit 8640039 failed the pnpm dependency-install step with exit 1 after 1 second. The log repeatedly said: Invalid package manager specification in package.json (pnpm@^12.15.0); expected a semver version. That is the available diagnosis: the launcher rejected the declared specification.
The record does not establish why the package was authored that way, which launcher version was active or whether a different supported toolchain would accept the checkout. We did not change the package metadata or retry the run. There is no completed build or test result in the supplied evidence, and no basis for a runner-speed claim.
The checkout contained 964 files, approximately 25,010 source lines and 5.1 MB. The scan found two CI workflow files, a tests directory and monorepo workspaces, with no Dockerfile. Those signals identify repository structure. They don't establish that upstream CI passes or that our environment matched the contributor requirements.
The configured sandbox had 3 CPUs, 8 GB RAM and image lab-node:22. Its label does not establish the actual runtime or operating-system version. Until a supported environment completes setup, this result should remain a bounded bootstrap finding rather than a verdict on AVA's assertions.
Explicit imports and asynchronous completion suit Node libraries
The README's examples import test from ava and use the supplied execution object for assertions. There are no implicit globals. Its documented assertion output includes source excerpts and diffs, which gives a library author a reason to inspect failing output during a trial. We haven't evaluated how readable that output is across a real project.
The writing guide says AVA waits for a returned promise and fails the test if it rejects. Async functions are supported, while test definitions themselves must be registered synchronously. These rules are concrete enough to check against a representative asynchronous function before migrating a whole suite. They also expose a boundary: delayed registration inside a timer isn't the documented model.
AVA requires a local installation, and its documentation assumes ES modules. Its Node support policy follows major versions still supported by Node.js, using their latest releases. Check the selected AVA version against your supported runtime matrix rather than copying the example dependency version from the README. Our sandbox label cannot answer that compatibility question.
Recent fixes show maintenance, not a passing lab run
The repository metadata records a last push on October 31, 2026. Release v8.3.0, published that day, lists contributor fixes for teardown re-entry, synchronous timeouts and title-prefix handling, plus a TypeScript documentation update. Those linked changes show current maintenance activity. We haven't reproduced their behavior or established that this release resolves our package-manager failure.
Documentation receives 3/5 on a narrow editorial scale: 1 means the evaluated workflow lacks usable instructions, 3 means a concrete documented path exists, and 5 requires independent verification throughout. The local-use examples and execution guide support the middle rating. Setup, community and maturity remain unassessed because supported setup, support capacity and runner behavior were not established.
Vitest shares Vite configuration; Mocha targets browsers too
Vitest documents reuse of Vite configuration, transformers, resolvers and plugins. Choose it for evaluation when keeping application and test transforms together is the main requirement. This is a workflow distinction, not evidence that Vitest runs faster than AVA.
Mocha describes itself as a test framework for Node.js and the browser. Consider it when those execution environments are central to your choice. AVA also links browser-testing recipes, so Mocha's positioning doesn't establish that browser integration with AVA is impossible.
For an AVA trial, start in your own supported Node project with the release you intend to use. Include an asynchronous operation and a case that changes shared external state, then inspect failure output and execution order. Resolve the contributor checkout's launcher requirement separately if you also intend to work on AVA itself.