@zerotal/testing 1.14.3 → 1.15.1

package/CHANGELOG.md

@@ -8,6 +8,48 @@ follows the Zerotal monorepo's unified versioning.
 
 ## [Unreleased]
 
+## [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
+
+- **A test that stubbed `globalThis.fetch` also answered the test client's own requests.**
+  `TestApp` drives the app over a loopback server through whatever `fetch` was current, so
+  faking an outbound integration — the ordinary way to test one — made unrelated route tests
+  fail with `connection refused`, or come back holding the third-party's JSON. The failure
+  presents as "my test client cannot reach my app", which sends you looking at the server.
+
+  `TestApp` now holds the real `fetch`, captured at module load before any test can replace
+  it. An outbound stub cannot intercept an inbound request, and no passthrough is needed for
+  the test client.
+
 ## [1.11.0] — 2026-08-31
 
 ### Changed

package/api-surface.md

@@ -3,6 +3,9 @@
 <!-- AUTO-GENERATED by scripts/api-surface.ts. Do not edit by hand.
      Run `bun run api:surface` to regenerate after an intentional API change. -->
 
+> Not a guide — this is a flat, alphabetical snapshot used to detect unintended
+> API changes. For how to use these, read the [documentation](https://zerotal.dev/docs).
+
 ## .  `(./src/index.ts)`
 
 class EventFake = {

package/package.json

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

package/src/TestApp.ts

@@ -5,6 +5,24 @@ import { resetTestState } from "./resetTestState.ts";
 
 type BunServer = { port: number; stop(drain?: boolean): void };
 
+/**
+ * The real `fetch`, captured at module load — before any test has had a chance
+ * to replace `globalThis.fetch`.
+ *
+ * The test client talks to the app over a real loopback server, so it used to
+ * call whatever `fetch` was current. A test that stubs `globalThis.fetch` to
+ * fake an outbound integration therefore also answered the test client's own
+ * requests: three unrelated route tests fail with `connection refused` or come
+ * back holding the third-party's JSON, and the failure reads as "my test client
+ * cannot reach my app", which sends you looking at the server.
+ *
+ * Binding it here means an outbound stub can never intercept an inbound request.
+ * A test that genuinely wants to intercept the test client has `app.app` and the
+ * router; a test that wants to stub an integration should not have to know this
+ * exists at all.
+ */
+const _fetch: typeof globalThis.fetch = globalThis.fetch.bind(globalThis);
+
 /**
  * Wrapper around a running Application that provides an HTTP test client.
  * Obtain an instance via createTestApp().
@@ -251,7 +269,7 @@ export class TestApp {
 
     if (this._errors) this._errors.lastError = undefined;
 
-    let res = await fetch(full, { ...init, headers, redirect: "manual" });
+    let res = await _fetch(full, { ...init, headers, redirect: "manual" });
 
     if (this._followRedirects) {
       let hops = 0;
@@ -267,7 +285,7 @@ export class TestApp {
           const cookiePair = setCookie.split(";")[0] ?? "";
           nextHeaders.set("Cookie", existing ? `${existing}; ${cookiePair}` : cookiePair);
         }
-        res = await fetch(nextUrl, { method: "GET", headers: nextHeaders, redirect: "manual" });
+        res = await _fetch(nextUrl, { method: "GET", headers: nextHeaders, redirect: "manual" });
         hops++;
       }
     }
@@ -431,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;
     }
@@ -650,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/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`
  *