Batch B (part 5): a test that passed for the opposite reason

[roncodes]

Two files. Stacked on #159 — review that one first.

addon/  1 file  +1  -0     ← one exclusion comment
tests/  2 files +45 -2
DEFECTS.md      +41

5054 pass / 0 fail / 0 skip. Branches 91.14% (from 91.07%), lines 95.07%.

file	gaps before	after
country-select	9	6
coordinates-input	9	7

The find here is a pre-existing test, not a coverage number

coordinates-input's "a geocoder response with no place reports nothing" primed fetch.responses['geocoder/query'] = null. But the dummy fetch service resolves responses[path] ?? [], so place was a truthy empty array:

• if (place) was taken, not skipped
• place.location.coordinates threw
• the catch swallowed it
• onGeocode was never called — so the assertion passed

The test asserts the right outcome for the opposite reason to the one it states, and the guard it names had never executed. It now overrides get to resolve null, asserts the null comes back uncoerced, and actually exercises the guard.

A third category in DEFECTS.md

That makes three tests found passing for a reason other than the one they name, now catalogued together:

test	claims	actually
coordinates-input "no place reports nothing"	the if (place) guard skips it	stub coerced null → [], so it threw and the catch swallowed it
chat-tray "every channel-shaped event is handled"	events are handled	unmatched names fall through the switch
filters-picker "an empty url value is treated as no value"	the component normalises it	getUrlParam does, one layer down (benign)

These are worse than an uncovered branch. An uncovered branch is visibly untested; a green test that describes behaviour it doesn't exercise will keep passing when that behaviour breaks. None are findable from a passing suite — only from reading branch counts against test intent.

A reusable trap worth knowing

tests/dummy/app/services/fetch.js resolves responses[path] ?? [], so the stub cannot express "resolved with nothing". Any test needing a falsy response must override get directly. Two tests in this repo primed null and silently received [].

Tests added

• a failed country lookup leaving an empty list — asserting on power-select's "No results found", which it renders as an option, so doesNotExist was the wrong assertion;
• selecting a country with no @onChange;
• a successful geocode with no @onGeocode.

New defect: #12 — ten now open

country-select's changed action is wired to nothing. The template uses handleChange for did-update and selectCountry for PowerSelect's @onChange, and yields nothing, so no consumer can reach it either.

Fourth instance of the orphaned-duplicate shape (#6, #9, #10, #12) — a second implementation sitting beside the one the template actually uses. Ten dead-code items now open; six are zero- or low-risk to delete.

My own process, recorded

Three attempts at one test here. The first approach was right and I abandoned it over an unrelated error inside it — the useful question when a fix fails is which part was wrong. After three tangled edits, git checkout HEAD -- and one careful pass was cheaper than re-reading my own half-applied changes.