Add test coverage tooling, real tests, and Codecov reporting

[roncodes]

Why

The test suite could not run at all. The dummy app failed to boot (@ember/string missing, required by ember-data 4.12), and CI ran only lint and build — so nothing exercised the addon. Of 138 test files, 128 were generated TODO: Replace this with your real tests stubs.

What

Test harness

• Add @ember/string so the dummy app boots.
• Declare ember-cli-string-helpers — an undeclared runtime dependency already imported by the crud service, humanize and get-model-name.
• Add packages to pnpm-workspace.yaml (required by pnpm 11).

Coverage

• Wire ember-cli-code-coverage, which needs three pieces that were all absent: config at the addon's configPath (tests/dummy/config/coverage.js), the istanbul babel plugin on both the dummy app and this addon's own tree, and a QUnit.done hook to ship the report. Instrumenting the addon tree is what makes coverage describe addon/ rather than only the dummy app.
• Force-load addon modules after the suite so files with no tests stay in the denominator instead of silently dropping out.
• scripts/check-coverage.mjs enforces per-file 100% and fails when an eligible addon/ file is missing from the report, so coverage cannot be inflated by omission. It has its own node:test suite covering both passing and failing paths.

Tests

• 54 generated stubs replaced with behavioral tests covering nullish, empty, boundary and invalid input. Suite is green: 259 tests, 0 failures.

CI

• Run the full suite with coverage and enforce the gate (previously no tests ran at all).
• checkout@v4, setup-node@v4 with pnpm cache, pnpm/action-setup@v4, --frozen-lockfile.
• Upload lcov to Codecov with fail_ci_if_error so a broken upload is visible.
• Least-privilege permissions, concurrency cancellation, publish jobs gated on the test job.

Status — work in progress

Not yet ready to merge:

• Coverage report is not yet produced. The suite passes but the run stalls in the QUnit.done hook. The /write-coverage middleware itself is confirmed working (a direct POST writes a report), so the remaining fault is on the browser side. No coverage percentage is claimed until a generated artifact exists.
• 75 generated stubs remain, plus the 26 services (one is ~1,976 lines).

Production defects found while reading source

Catalogued, not yet fixed:

1. utils/extract-coordinates.js — copy/paste typo sets latitude = 0 where it means longitude = 0.
2. Four utils (api-url, console-url, frontend-url, get-routing-host) import @fleetbase/console/config/environment, hard-coupling the addon to one consuming app. The addon's own convention elsewhere is ember-get-config. This also makes them impossible to load in tests.
3. services/universe/extension-manager.js imports a function from the host app (@fleetbase/console/extensions).
4. utils/is-waypoint-record.js imports ../models/waypoint, which does not exist — the module can never be imported by anyone.
5. utils/is-relation-missing.js contains isset(model, ''), which is always falsy, so one branch is dead.

Four utils ignore their arguments and always return true (ison, reverse-point, is-function, hason-structure); get-mime-type returns an extension rather than a mime type. Current behavior is pinned by tests with NOTE comments rather than silently changed.

🤖 Generated with Claude Code

[codecov]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️

[roncodes]

Two of the three "structural" files were not structural

Coverage at 9510ac9: statements 3761/4025 (93.44%), branches 90.86%, functions 97.08%, lines 93.37%. 2103 tests, 0 failing. Up from 89.61% at the start of this stretch.

DEFECTS.md is now at the repo root — all 24 findings in one place, grouped by live / dead code / latent, each naming the test that pins it. These PR comments remain the running log.

The part worth reading

I had recorded three files as structurally uncoverable, holding 377 of the ~420 remaining statements. Two of them were not. Both went from a written-off note to covered in a single round each, once I read what the code actually calls instead of describing the dependency as heavy.

universe/extension-manager — 230 uncovered, now 137. The note said "engine construction needs a real engine in the container". It does not. #loadEngine drives the router's private engine API:

router._enginePromises / router._engineIsLoaded / router._assetLoader.loadBundle / router._registerEngine

and constructEngineInstance only calls application.hasRegistration, application.buildChildEngineInstance and engineInstance.boot(). All of it is reachable through a fake application handed to the service before it is built. No bundle is loaded and nothing touches the network.

services/fetch — 88 uncovered, now 64. The note said request() calls the module-scope fetch from ember-fetch, so it cannot be stubbed. Half right: window.fetch genuinely does not reach it — this build does not prefer native fetch, so ember-fetch bundles the github/fetch polyfill onto its own exports, which is why swapping the global changed nothing and the requests went out for real. But under a test environment ember-fetch's default export is a wrapper that reads exports.fetch at call time, and exports is the AMD module object:

const m = window.require('fetch');
const original = m.fetch;
m.fetch = stub;   // restored in teardown

That intercepts every call the service makes.

That is the fifth and sixth time in this PR I have called something untestable and been wrong. The pattern is identical every time: I described the dependency instead of reading what the code calls on it.

Also this round

uploadFile needed no seam at all — the file is an argument. download's GET/POST split, external requests, and header-derived filename and mime type are covered, and its hand-off to the vendored downloadjs helper now runs for real against a small in-memory blob.

One new defect (24 total). getMimeTypeFromResponse extracts with /(.*)?;/.exec(contentType), which requires a trailing semicolon — so a bare Content-Type: text/csv, the common case, matches nothing and the mime type stays null. download() then falls through to getMimeType(fileName), which returns the extension, so the browser is handed 'csv' where 'text/csv' was meant. Also pinned: the content-disposition header overrides a caller-supplied filename rather than falling back to it.

Where the gate stands

264 statements remain, and they are honestly reachable except for one category:

statements	file	status
137	extension-manager	reachable — loadExtensions, setupExtensions, the owner patch, the hook plumbing
64	services/fetch	reachable — routing() goes through corslite/XMLHttpRequest, plus fetchOrderConfigurations
59	utils/download.js	vendored downloadjs, now partly exercised through fetch.download
~9	~10 other files	includes seven dead-code defects that no test can reach

So the 100% gate cannot be reached while defects are flagged rather than fixed: #16–#21 and #23 are unreachable by construction, and their statements need the fix pass, not more tests. Everything else on that list is ordinary work and I am continuing with it.

[roncodes]

All three "structural" files are covered. None of them was structural.

Coverage at 760c971: statements 3861/4025 (95.92%), branches 93.14%, functions 98.01%, lines 95.91%. 2146 tests, 0 failing. Three rounds, all green first try.

I carried three files as uncoverable for most of this campaign — 377 statements, about 88% of the remaining gap at the time. Each fell in a single round once I stopped describing the dependency and read what the code actually calls on it.

file	the note I had written	what was actually true
extension-manager	"engine construction needs a real engine in the container"	it drives the router's private engine API; the boot half needs a global-fetch swap plus redirecting getExtensionLoader, which the dummy app already AMD-stubs
services/fetch	"request() calls the module-scope fetch, so it cannot be stubbed"	window.fetch genuinely cannot reach it, but window.require('fetch').fetch can — the test-mode default export reads exports.fetch at call time
utils/download.js	"vendored downloadjs; triggers real downloads/XHR"	the anchor comes from document.createElement('a'), so wrapping createElement makes the click a no-op and nothing is saved; the url-only path uses the global XMLHttpRequest

That is six times in this PR I have called something untestable and been wrong, with the same mistake every time: I described the dependency as heavy — "module-scope import", "needs a real engine", "triggers real downloads" — instead of reading which of its members the code touches.

The technique that generalises

In a classic build, import { x } from 'm' compiles to a property read on the module object at call time. So any module-scope import is interceptable:

const m = window.require('m');
const original = m.x;
m.x = stub;          // restored in afterEach

Confirmed on both fetch and @fleetbase/console/extensions. Worth knowing for anything else in this codebase that looks bolted down.

Covered in these three rounds

• extension-manager's boot half — the core/admin/installed filtering, the failure path that empties the application and still releases the boot waiters, and all six shapes an extension.js can export: a function, a default-wrapped function, an object with setupExtension, one with onEngineLoaded (stored, not run), one with neither (warned), and a loader that throws without stopping the others.
• fetch.routing and corslite — url assembly, the three response outcomes, and corslite's failing-status, 304, no-XMLHttpRequest and IE8-9 XDomainRequest paths.
• download.js — the blob path and the anchor's full lifecycle, plain and high-byte strings, data urls, the url-only path that re-fetches as a blob, the bind(true) argument reversal the original library documents, and the IE10 msSaveBlob preference.

Where the gate stands

164 statements remain. 77 in extension-manager (the owner patch, engine parent dependencies, hook plumbing), 34 in download.js (Safari and iframe fallbacks — browser-capability branches Chrome cannot take without faking the capability checks), 10 in fetch, and about 43 spread thin.

That last group still includes the seven dead-code defects, which no test can execute. So 100% remains out of reach while defects are flagged rather than fixed — but the gap is now genuinely small and almost all of it is ordinary work rather than anything structural.

[roncodes]

DEFECT.md is on the branch, with the gate blockers verified and up front

DEFECT.md at the repo root now carries all 26 findings. It leads with the section that actually matters for this PR: exactly what stops the 100% gate going green.

⛔ Six defects, ten statements

#	file	lines	why no input reaches it
B1	contracts/widget.js	239, 255	the constructor already assigns this.options on both paths, so if (!this.options) never fires
B2	services/resource-action.js	209, 233	if (!selected) after a spread — always a truthy array
B3	services/universe/menu-service.js	51	#wrapOnClickHandler's type check duplicates its only caller's
B4	services/url-search-params.js	176	clear()'s return this sits after a line that throws every time
B5	utils/to-model.js	8, 10	getOwner() is undefined, so the line above throws on every call
B6	services/universe/hook-service.js	81	its only caller runs in the constructor, before setApplicationInstance can have run

Five of the six are a deletion; B6 is a reordering.

I had this wrong, and the artifact corrected it

I have been repeating "seven defects block coverage" from memory. Checking it against coverage-final.json rather than my notes:

• auto-serialize's dead invoke dispatch and its fleet/zone patches are no longer blockers. The pinning tests reach both — one via a model carrying a property literally called method, the other by supplying the removed _internalModel path with Object.defineProperty. That file is at 100%.
• loadWhois's catch is covered too, through a storage write that throws after lookupUserIp returns.

So it is six, not seven, and the blocked total is ten statements rather than a vague handful.

A category I had been conflating with defects

Twelve more statements cannot be covered either, but are not bugs and need no fix:

• @tracked field = value initialisers that a constructor overwrites (5) — the initialiser only runs if the property is read before it is written, and these classes assign in the constructor. An instrumentation artifact.
• Fallbacks that need a container-less service (6) — if (!owner) / if (!application) paths. Ember always supplies an owner, and the one substitute that would work breaks the run: ApplicationInstance#willDestroy reads this.application._unwatchInstance during teardown.
• One module-scope config line that runs at import time.

If the gate has to go green without touching production code, those twelve are the only honest candidates for an exclusion — and I would not add one without you asking, since the scope decision was explicitly to keep writing tests instead.

Current coverage, from CI run 31240648459: statements 3861/4025 (95.92%), branches 93.14%, functions 98.01%, lines 95.91%. 2146 tests, 0 failing.

[roncodes]

97.96%, and I aborted the run once getting there

Coverage at 53d404c: statements 3943/4025 (97.96%), branches 94.74%, functions 98.74%, lines 97.93%. 2173 tests, 0 failing.

Two rounds since the last update:

• extension-manager's hook plumbing and parent-dependency fixing (+56). The owner patch wraps buildChildEngineInstance so engines loaded through routing get the same treatment as ones loaded through this service, and covering it reaches everything hanging off it: onEngineLoaded hooks stored before load and run after boot, run immediately when the engine is already loaded, isolated when one throws, and fired exactly once even though two separate paths could fire them. Plus hostRouter mapping to service:router rather than service:hostRouter, external routes becoming a self-referencing map, and the mount point's trailing dot being stripped.
• downloadjs's browser fallbacks (+26) — the Safari window.open route including the mime rewrite that makes it offer to save rather than render, the blocked-popup path, the old iframe route and its cleanup, and the two-megabyte threshold where a data url is decoded into a blob rather than handed over whole.

The abort, because the mechanism is worth knowing

The download-fallbacks commit killed the run: 1680 of 2173 tests, then Browser timeout exceeded: 10s.

To reach the non-a[download] path I replaced document.createElement so anchors came back as spans — for the duration of the test. QUnit's own HTML reporter creates anchors. It got spans, reporting stalled, and testem's watchdog killed the browser.

The tell I'd written down after an earlier incident worked exactly as intended: a pass count far below the known total means an aborted run, not N failures. That pointed at the cause immediately instead of sending me hunting through assertions.

The fix is a rule rather than a patch: install a global override around the call and remove it in a finally, never for a whole test — for anything the test framework also uses (document.createElement, window.URL, navigator.*). window.fetch and XMLHttpRequest are safe to hold for a test because the framework doesn't use them. I also dropped two tests that deleted window.URL: same blast radius, and two statements is not worth it.

What is left — 82 statements

~40	genuinely reachable work (fetchOrderConfigurations, socket's async-iterator callback, load-extensions, lookup-user-ip, a scattering of one-liners)
10	⛔ the six gate-blocking defects — see DEFECT.md
12	uncoverable but not defects — @tracked initialisers a constructor overwrites, if (!owner) fallbacks needing a container-less service, one module-scope config line
10	downloadjs's no-URL/FileReader route — reachable only by deleting window.URL, which aborts the run as above. Not worth it.

So the reachable remainder is around forty statements. Past that the number needs either the fix pass for the six defects, or a decision from you about the twenty-two that no test can reach.

[roncodes]

98.33%, and a green test that was hiding a dead branch

Coverage at e1755d3: statements 3958/4025 (98.33%), branches 95.15%, functions 98.74%, lines 98.31%. 2194 tests, 0 failing.

Covered this round: request's normalizeToEmberData branch, the half of uploadFile that turns the response into a store record, the body of socket.listen's async-iteration loop, and the last one-liners — from-store/legacy-from-store's onComplete, serialize-model's toJSON branch, theme's prefers-color-scheme check and language's swallowed save failure.

An earlier test of mine was passing for the wrong reason

The first uploadFile tests registered no model:file. So store.normalize('file', …) threw, the method's outer catch swallowed it, and the tests still passed — because they only asserted what was sent, never what came back. The entire success half of that method had never executed while looking covered by a green test.

Registering a real model made it run for the first time, and reaching the outer catch deliberately (a payload with no uuid) covered the failure half properly. The general lesson: a test that only asserts the request tells you nothing about the response handling, and can sit there green over a dead branch indefinitely.

One more defect (27 total)

filters.activeFilters loops over getQueryParams() and skips entries that are blank or managed:

if (isBlank(value) || this.managedQueryParams.includes(queryParam)) continue;

But getQueryParams() — called with no controller, so taking the route path — has already dropped both: it skips managed params and only adds a value if (value). The continue is unreachable and the filtering is duplicated one layer apart.

Also noted, not a defect: theme's final fallback returns this.currentTheme, not the literal 'dark' its comment claims. The comment is misleading rather than the code being wrong.

Two CI rounds lost to the same pre-flight I keep writing down

theme's accessor is activeTheme, a getter — not getTheme(), which I invented. And LanguageService reads intl.locales/intl.primaryLocale and calls intl.onLocaleChanged in its constructor, so a bare service stub threw at lookup before either test body ran. One grep for this.<collaborator>. plus a glance at the accessor's real name would have caught both together.

What is left — 67 statements, of which about ten are reachable

23	extension-manager — #getApplication fallbacks and boot-state accessors, several of which are in the not-a-defect group below
10	⛔ the six gate-blocking defects (DEFECTS.md)
12	uncoverable but not defects — @tracked initialisers a constructor overwrites, if (!owner) fallbacks needing a container-less service, one module-scope line
10	download.js's no-URL route — needs deleting window.URL, which aborts the run
~10	genuinely reachable: corslite, load-extensions, lookup-user-ip, legacy-fetch-from, report-actions — mostly localStorage/Intl catch blocks needing a scoped global override

The reachable remainder is now roughly ten statements. Past that, the number needs the fix pass for the six defects, or a decision about the twenty-two that no test can reach.

[roncodes]

Reachable coverage is complete — 98.95%, and what is left needs your decision

Final state at 5fed152 (CI run 31245775305): statements 3983/4025 (98.95%), branches 95.52%, functions 99.58%, lines 98.96%. 2215 tests, 0 failing.

Every statement a test can reach is now covered. The 42 that remain are itemised exactly in DEFECTS.md, read off the coverage artifact rather than from memory, and none of them can be executed by any input.

Covered in these last rounds: the localStorage and Intl catch blocks in load-extensions and lookup-user-ip, corslite's synchronous-callback deferral, legacy-fetch-from's prototype accessor, report-actions' edit modal, fetch's upload error callback, and the extension manager's remaining edges — the boot-state setters, the in-flight and already-built short circuits, the registration failures, and the second of its two engine-loaded hook paths, which only runs for an instance that arrives already boot-patched.

⛔ Seven defects, ten statements, block the gate

file	lines	why
contracts/widget.js	239, 255	the constructor assigns this.options on both paths, so if (!this.options) never fires
services/resource-action.js	209, 233	if (!selected) after a spread — always a truthy array
services/universe/menu-service.js	51	the type check duplicates its only caller's
services/url-search-params.js	176	return this sits after a line that throws every time
utils/to-model.js	8, 10	getOwner() is undefined, so the line above throws first
services/universe/hook-service.js	81	its only caller runs in the constructor
services/filters.js	25	the list it filters was already filtered by getQueryParams()

Six of the seven are a deletion. hook-service is a reordering — move #initializeHookRegistry() out of the constructor.

And 32 that are uncoverable but are not bugs

• 6 — @tracked field = value initialisers a constructor overwrites. The initialiser only runs if the property is read before it is written. An instrumentation artifact.
• 12 — if (!owner) / if (!application) fallbacks. Ember always supplies an owner, and the one substitute that would work breaks the run (willDestroy reads this.application._unwatchInstance).
• 10 — download.js's no-URL route. Deleting window.URL stalls QUnit's reporter and aborts the run, and one line assigns location.href, which would navigate away from the test page.
• 2 — module-scope config that runs at import.
• 2 — a hook path the boot patch always wins.

That second group is the only honest candidate for a coverage exclusion. I have not added one, because the scope decision was explicitly to keep writing tests instead — that is yours to reverse.

Two things I got wrong this round, both caught by assertions rather than luck

A synchronous try/finally around an async call restores the global the moment the promise is returned, long before the code under test writes anything. Both cache-failure tests passed their overrides and wrote to localStorage normally; the "nothing was cached" assertions are what caught it. The fix is an async helper that awaits inside the try.

And I shipped another assert.true(true, …) into a draft, for the cache-clear test. It now seeds a key, breaks removeItem, and asserts the key survived — the observable thing. That is the third vacuous assertion I have caught in my own work on this PR; writing the rule down has not stopped me producing them, only reading the diff has.

Where this leaves the PR

The suite is green at 2215 tests. Coverage is 98.95% and cannot move further under the flag-only directive. The next step is yours: either let me do the batched fix pass for the seven defects — which would take the gate to roughly 99.2% — or decide about the 32 uncoverable statements.