Repository navigation
Support consistent transactional tests across Jest, Vitest, and database clients - #1
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Database integration tests can now use the same file declaration and typed transaction context under Jest and Vitest, with Prisma, pg, or TypeORM. The existing decorator, lifecycle manager, adapter contract, Vitest configuration signature, and package entrypoints remain available.
Each test attempt holds one rollback-only transaction across its fixtures, body, and teardown. The Jest Node environment integrates through public Circus events and a sandbox-local bridge. Shared session handling bounds acquisition and rollback, invalidates completed contexts, and keeps cleanup errors visible even for expected-failure tests and retries. TypeORM uses a dedicated QueryRunner and transaction-bound EntityManager.
Shared database migrations run once before workers.
prepareDatabaseis explicitly documented as a per-file hook. The complete NestJS inventory example lives in this repository alongside the smaller examples. It includes versioned application migrations, explicit provider overrides, both runners, all supported clients, and handwritten pg baselines. The README leads with the published@integration-testing/testcontainerspackage and also documents external databases and SQLite.Examples are not shipped to npm. Only
packages/datais published, with compiled outputs, declarations, README, license, and package metadata. Package checks reject example, migration, and vendor paths and verify that a core-only consumer does not install NestJS. The consumer gate copies the repository example to a temporary directory outside the workspace and installs a freshly packed library artifact. It no longer clones or depends on a separate demo repository.Validation: 25 unit tests; 42 child-process lifecycle cases on current runners and another 42 with Jest 30.1.0; ESM/CommonJS runtime and declaration checks; optional dependency independence; eight real runner/client/database combinations; 38 intentionally failing database processes with nonzero exit and independent rollback verification; external URL and separate-schema coverage. The relocated example also passes local SQLite execution and the installed-package consumer matrix. CI passed for commit 9dd69ea.
The prepared candidate remains
0.1.0-beta.0; npm returned package-not-found when the candidate version was selected. No npm publication is performed. HTTP requests, unrelated connections, background workers, explicit commits, and concurrent tests within a file remain outside the rollback guarantee; runner timeouts do not forcibly cancel JavaScript.