@zerotal/testing 1.15.0 → 1.15.2

package/CHANGELOG.md

@@ -8,6 +8,43 @@ follows the Zerotal monorepo's unified versioning.
 
 ## [Unreleased]
 
+## [1.15.2] — 2026-10-23
+
+### Fixed
+
+- **`assertDatabaseHas`, `assertDatabaseMissing` and `assertDatabaseCount` run on Bun
+  1.4.4.** They counted rows through a hand-built template object whose `raw` was
+  enumerable, which Bun 1.4.4 refuses. They use the ORM's `_templateStrings()` now; see
+  `@zerotal/orm`.
+
+## [1.15.1] — 2026-09-13
+
+### Fixed
+
+- **A file that booted the app with a `setup` callback left every later file without a
+  database.** `createTestApp(bootstrap, setup)` opts out of _sharing_, because `setup`
+  registers routes and those cannot be added twice to a running server — and
+  `FlowBrowser.serve` always passes one. But "not shared" was implemented as "not cached",
+  which is a much bigger claim: `bootstrap/app.ts` is module-cached, so the `Application`
+  behind it is the one every later file's `bootstrap()` returns.
+
+  Being invisible to the cache meant nothing knew it was in use, so its `close()` ran the
+  full provider teardown. `DatabaseProvider.onStopping` clears the process-global
+  connection resolver, and the next file then got that same stopped `Application` back —
+  `Application.create()` short-circuits on a module-cached app, so the providers never
+  re-registered and nothing put the resolver back. Every query from then on raised
+  `[Zerotal ORM] No database connection. Is DatabaseProvider registered?` in files that
+  had done nothing wrong.
+
+  The app is now cached whichever call booted it. `_shared` still means "reached through
+  the sharing path", and a second `setup` caller still gets the fresh path it needs — only
+  the bookkeeping changed.
+
+  It read as a CI-only flake for months because the exposing order is a browser-driven
+  file before an ordinary one: alphabetical on Windows, arbitrary readdir order on Linux.
+  Reproduced locally by renaming the one ordinary file to sort last (62 pass / 49 fail),
+  and verified at 111 / 0 across seven runs in both orders.
+
 ## [1.15.0] — 2026-09-04
 
 ### Fixed

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zerotal/testing",
-  "version": "1.15.0",
+  "version": "1.15.2",
   "license": "MIT",
   "maturity": "stable",
   "private": false,
@@ -32,14 +32,14 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@zerotal/core": "1.15.0",
-    "@zerotal/orm": "1.15.0",
-    "@zerotal/queue": "1.15.0",
-    "@zerotal/notifications": "1.15.0"
+    "@zerotal/core": "1.15.2",
+    "@zerotal/orm": "1.15.2",
+    "@zerotal/queue": "1.15.2",
+    "@zerotal/notifications": "1.15.2"
   },
   "devDependencies": {
     "typescript": "^5.8.0",
-    "@zerotal/session": "1.15.0"
+    "@zerotal/session": "1.15.2"
   },
   "description": "Testing utilities for Zerotal — an in-process test app, HTTP helpers, and database refresh.",
   "keywords": [

package/src/TestApp.ts

@@ -449,7 +449,23 @@ export class TestApp {
    * The shared instance is torn down once, by {@link closeSharedTestApps}.
    */
   async close(): Promise<void> {
-    if (this._shared) {
+    // `_shared` says this wrapper came from the sharing path. It is not the same
+    // question as whether the *Application* is shared — a `bootstrap/app.ts` is
+    // module-cached, so a `createTestApp(bootstrap, setup)` call (which opts out of
+    // sharing, because `setup` registers routes and those cannot be added twice to
+    // a running server) is handed the very same `Application` the shared wrapper
+    // holds. `FlowBrowser.serve` always passes a `setup`.
+    //
+    // Tearing down here would then stop an Application somebody else is still
+    // using, closing the process-global database connection out from under every
+    // later file: they fail on their first query with "No database connection. Is
+    // DatabaseProvider registered?", in files that are entirely correct and merely
+    // ran second. The ordering that exposes it — a browser-driven file before an
+    // ordinary one — is alphabetical on Windows and arbitrary on Linux, so it read
+    // as a CI-only flake for months.
+    //
+    // So the question to ask is about the Application, not the wrapper.
+    if (this._shared || _sharedApps.has(this._app)) {
       resetTestState();
       return;
     }
@@ -668,10 +684,22 @@ export async function createTestApp(
   await app.start(0);
   const testApp = new TestApp(app, errors);
 
-  if (!setup) {
-    testApp._shared = true;
-    _sharedApps.set(app, testApp);
-  }
+  // Cache it either way. `_shared` still means "reached through the sharing path",
+  // and only a `setup`-free call is handed one back — a second `setup` caller has
+  // routes to register and needs the fresh path. But the *Application* is
+  // module-cached and every later file will ask for it, so it has to be findable
+  // regardless of which call happened to boot it first.
+  //
+  // Without this, an app booted by `FlowBrowser.serve` (which always passes a
+  // `setup`) was invisible here, so nothing knew it was in use: its `close()` ran
+  // the full teardown, `DatabaseProvider.onStopping` cleared the process-global
+  // connection resolver, and the next file's `bootstrap()` returned that same dead
+  // Application — `Application.create()` short-circuits on a module-cached app, so
+  // the providers never re-registered and nothing ever put the resolver back. Every
+  // query after that raised "No database connection. Is DatabaseProvider
+  // registered?" in a file that had done nothing wrong.
+  testApp._shared = !setup;
+  _sharedApps.set(app, testApp);
   return testApp;
 }
 

package/src/assertions.ts

@@ -1,4 +1,4 @@
-import { _getModelConnection } from "@zerotal/orm";
+import { _getModelConnection, _templateStrings } from "@zerotal/orm";
 
 async function countRows(table: string, where: Record<string, unknown>): Promise<number> {
   const conn = _getModelConnection() as unknown as (
@@ -19,7 +19,7 @@ async function countRows(table: string, where: Record<string, unknown>): Promise
   });
   parts.push(sql);
 
-  const tpl = Object.assign([...parts], { raw: [...parts] }) as unknown as TemplateStringsArray;
+  const tpl = _templateStrings(parts);
   const rows = await conn(tpl, ...vals);
   return Number(rows[0]?.cnt ?? 0);
 }

package/src/preload.ts

@@ -7,8 +7,20 @@
  * TestCommand) and calls _setBaseModelConnection + _setDbConnection so that
  * withDatabase() and DB.table() work without any manual beforeAll setup.
  *
- * Each Bun test worker runs its own copy of this module, so connections are
- * isolated per file — no cross-file leakage.
+ * Each Bun test *worker* evaluates this module once — not once per file. Every
+ * file that worker runs therefore shares the connection wired here, and shares
+ * every other piece of module-level state in the process with it.
+ *
+ * This used to read "isolated per file — no cross-file leakage", which is the
+ * assumption that let five separate cross-file leaks hide: a `document` stub, a
+ * runtime-mode variable, an ORM dialect, and two whole booted applications, each
+ * set by one file and read by another. Verified rather than assumed — a hook
+ * registered here runs once at the end of a run, not once per file.
+ *
+ * So a test that mutates process-global state has to put it back, and the reason
+ * it is easy to skip is that the damage lands somewhere else: the file that
+ * breaks is the one that ran next, and which file that is depends on directory
+ * order — alphabetical on Windows, arbitrary on Linux.
  *
  * ## Why the runtime check is here and not only in `zt test`
  *