PubTrivia Test Suite Has No DOM: 266 Tests in 603 Milliseconds
Discover how the PubTrivia Next.js project runs 266 tests in just 603 milliseconds without using jsdom, happy-dom, or any Testing Library.

Stock photo for illustration only, not from the actual event
- PubTrivia executes 266 tests in a mere 603 milliseconds without a DOM environment
- The test suite consists of 16 files and 3,201 lines of code in total
- Only one file interacts with a database, spanning the longest at 543 lines
- The repository lacks code coverage reporting and active linter commands
The Next.js application PubTrivia, which contains 201 .tsx files with 52 designated as client components, has shared an unconventional testing strategy utilizing zero browser-like environments. Checking the package.json file reveals the absolute absence of jsdom, happy-dom, or Testing Library packages.
The test configuration spans a mere eleven lines. According to the vitest list output, the suite contains 266 tests distributed across 16 files totaling 3,201 lines. Thirteen of these tests require a database connection, while the remaining 253 tests require no external dependencies at all. The run results show 15 test files passed and 253 tests passed in a duration of 603 milliseconds.

Stock photo for illustration only, not from the actual event
Among the test files, four invoke vi.mock, while twelve mock nothing since there is nothing to mock, simply importing and calling a module directly. The most notable file is pricing/price-copy.test.ts, which tests an actual React component by reaching for the server renderer in the complete absence of a DOM.
"The limits are real. Nothing here can click. No test in this repository has ever fired an event, checked a focus ring, or asserted that a dialog closes."
Daniel Pertu
These limitations are deliberate. No test in this repository has ever triggered a click event, verified a focus ring, or asserted a dialog closure. For a codebase designed to protect revenue and metadata, this is a defensible trade-off, though one worth acknowledging explicitly rather than discovering unexpectedly later.
Adopting a DOM-less testing approach in Next.js applications demonstrates how developers can bypass heavy browser-emulation tools to achieve blazing-fast execution speeds in the millisecond range. However, this trade-off sacrifices the ability to test complex user interface interactions and visual regressions, making it primarily suited for projects focused heavily on backend logic, data integrity, and server-side rendering rules.
Furthermore, certain test files evaluate code by reading source strings via regular expressions rather than executing them directly, such as the page metadata test which extracts exported constants to prevent booting external services like Supabase during test runs.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment