Three test-suite blind spots: no visual baseline, nothing against Apple, no realistic tag count

[parawanderer]

Three gaps, grouped because they share a cause

The instrumented suite is now strong at "this screen broke" and adequate at "this logic is
wrong". These are the classes of failure it still cannot see. None is urgent; all three are worth
knowing about before trusting a green run.

1. No visual baseline

Screenshots are produced — SystemColorsLayoutTest and friends draw layouts to bitmaps that AGP
copies back to the host — but nothing compares them to anything. They explain a failure; they
cannot cause one.

So a layout regression is caught only where somebody wrote an explicit measurement: a resolved
colour, a contrast ratio, a measured height, a card's width. Where nobody did, a screen can change
shape completely and every test stays green.

That is deliberate as far as it goes — AGENTS.md rule 12 says a screenshot is not an assertion,
and the card and icon tests follow it by asserting numbers. But it means "the UI is covered" is
true only for the specific properties somebody thought to pin.

Option: a golden-image comparison for a handful of key screens, with a documented way to
re-bless them. The usual objection applies — image diffs are flaky across renderers and API levels
— so it may be worth doing for two or three screens rather than broadly.

2. Nothing runs against Apple

Inherent, already documented in CONTRIBUTING, and repeated here so it sits with its siblings: every
Apple-facing test proves this app is correct about a protocol it cannot check. If Apple changes an
endpoint, a header or a payload, the whole suite stays green and the app stops working.

There is no fix, only awareness. It is the strongest argument for keeping the failure paths
well-covered — see FakeAppleAuthService and the two Python doubles — since what users meet when
Apple moves is an error path.

3. No test uses a realistic number of tags

Everything runs with two to four tags. A well-equipped account holds more like six to twelve —
and note that the list is not only AirTags: reading the account pulls in the user's own Apple
hardware too, so an iPad, a second iPad and a MacBook sit in it alongside the wallet and the
backpack.

That is two or three times what the tests use rather than an order of magnitude, so this is worth
keeping in proportion. It still matters, because the behaviours most likely to misbehave with more
tags are exactly the ones nobody exercises with more than four:

• the tag carousel — settling and measuring across ten cards rather than three
• scan ordering and the backoff — designed around a batch being abandoned part way, which
  gets likelier the longer the batch is
• the first-import wait, which is the slowest thing the app does and scales with tag count

FakeICloudService.withManyDevices(count) already exists for the device picker, so the fixture
idea is proven; AMapWithTagsOnIt.seed(...) takes varargs and would extend easily.

Probably the one most likely to find something, because the first import is the slowest thing
the app does and its cost scales with the number of tags. Not because anybody owns thirty of them.

The screen where large numbers are genuinely real is the escrow device picker, which is why
FakeICloudService.withManyDevices(count) already exists: escrow records outlive the hardware that
created them, so somebody with a decade of Apple devices has a long list to scroll. That case is
already covered.

---

🤖 Written by Claude Code