tests: 108 it.todo placeholders make the suite mostly aspirational

[dobby-coder]

Problem

npm test currently reports:

```
Test Files 2 passed | 7 skipped (9)
Tests 21 passed | 108 todo (129)
```

Per-file todo counts:

File	it.todo
crypto-popup.test.ts	23
state.test.ts	18
encryption-flow.test.ts	21
decryption-flow.test.ts	19
message-routing.test.ts	11
detection.test.ts	8
sent-copy.test.ts	8

Each file is essentially a doc string of describe/it.todo lines with no implementation — the entire file gets skipped at runtime. As a result the suite gives a false sense of coverage: 21 passing tests, all in encoding.test.ts and utils.test.ts (pure helpers), while the encryption/decryption/state-management code that PR #68 specifically fixed has zero behavioural tests.

Suggested approach

Pick one of:

1. Implement — wire up a minimal browser.* mock harness (most of these tests need browser.tabs, browser.compose, browser.windows, browser.storage.local). Starting with state.test.ts would cover the lifecycle code touched by PR fix: prevent unencrypted send when encryption is enabled #68. Issue Integration tests #53 ("Integration tests") tracks higher-level end-to-end coverage; this issue is the unit-test gap underneath it.
2. Delete — if these will not be implemented soon, remove the placeholder files so the test report reflects reality. The todo list can move to a tracking issue or `tests/README.md`.

Mixing the two is also fine — the core problem is that all 108 are sitting in the suite as no-ops.

Files

• `tests/crypto-popup.test.ts`
• `tests/state.test.ts`
• `tests/encryption-flow.test.ts`
• `tests/decryption-flow.test.ts`
• `tests/message-routing.test.ts`
• `tests/detection.test.ts`
• `tests/sent-copy.test.ts`

Related: #53.

[rubenhensen]

/dobby start implementing these tests.

[dobby-coder]

Dobby hears the call! Dobby will start implementing the tests, beginning with the browser.* mock harness and state.test.ts (PR #68 lifecycle code), then expanding outward. Dobby is most excited to write real tests!

[dobby-coder]

Plan

This is a big surface (108 todos across 7 files). Most of the placeholders live in code that is currently inside background.ts and not exported, so without refactoring nothing can be tested in isolation. Proposing an incremental approach: ship the foundation + the highest-value file first, follow up per file.

Step 1 — Foundation (this PR)

1. Browser API mock harness (tests/helpers/browser-mock.ts):

   • Minimal in-memory mocks for browser.storage.local, browser.tabs, browser.windows, browser.compose, browser.messages, browser.notifications, browser.runtime, browser.i18n, browser.composeAction, browser.scripting, browser.messageDisplayAction, browser.messageDisplayScripts.
   • Exposed as installBrowserMock() (sets up globalThis.browser and resets state) so each test starts clean.
   • Per [[vitest-mock-hoisting]]: define the mock object inside vi.hoisted if any test ends up using vi.mock factory, otherwise pure setter is fine.

2. State refactor — extract the small amount of logic currently in background.ts that the tests target, into state.ts so it can be unit-tested without spinning up the whole background script:

   • toggleEncrypt(tabId) — pure-ish, only touches composeTabs + persistence + delivery-format update.
   • cleanupComposeTab(tabId) — removes maps entries.
   • cleanupDecryptedMessage(msgId) — used by messages.onDeleted.
   • The existing handleToggleEncryption / cleanup handlers in background.ts become thin wrappers around these. No behavior change.

3. Implement tests/state.test.ts fully (18 tests):

   • Lifecycle: initialize on compose-created, auto-enable on encrypted reply, no auto-enable on plain reply / new msg, cleanup on tab close.
   • Toggle: state flip, deliveryFormat switching, hasRecipients return value.
   • decryptedMessages cleanup, no-crash on unknown ID.
   • Pending popup maps: reject on window close, no stale entries, dedupe per compose tab.

4. Implement tests/detection.test.ts (8 tests) — isPGEncrypted / wasPGEncrypted are small, narrowly-scoped, and only need browser.messages mocks. Extract them from background.ts into src/lib/detection.ts (already imported there).

Step 2 — Follow-ups (separate PRs, tracked in this issue)

• crypto-popup.test.ts (23) — needs an SDK mock for @e4a/pg-js. Larger lift; deserves its own PR.
• encryption-flow.test.ts (21) — handleBeforeSend. Heavy refactor of background.ts.
• decryption-flow.test.ts (19) — handleDecryptMessage.
• message-routing.test.ts (11) — extract the runtime.onMessage switch into a routed dispatcher.
• sent-copy.test.ts (8) — onAfterSend handler.

Risk / care

• PR fix: prevent unencrypted send when encryption is enabled #68's persistence fix is exactly the lifecycle code being tested — care to keep the existing guards (composeTabs.has() check before set, persistence on toggle). Tests should pin those behaviors so future refactors can't regress them.
• Per [[tests-required-on-fixes]]: this issue exists because PR fix: prevent unencrypted send when encryption is enabled #68 fixed real bugs without behavioral coverage. The state-lifecycle tests are the priority.

Verification

• npm test — target jumps from "21 passed | 108 todo" to ~"47 passed | 82 todo" after this PR.
• npm run typecheck — must stay green.
• npm run build:dev — must build.

Draft PR will be opened against main. Reviewer: rubenhensen.

[dobby-coder]

First slice shipped as draft PR #110: foundation (browser-mock harness) + state.test.ts (23 tests) + detection.test.ts (8 tests). Test report jumps from 21→52 passing, 108→82 todo. Kept as draft for review of the small extractions out of background.ts (pure relocation, no behavior change). Follow-ups for crypto-popup / encryption-flow / decryption-flow / message-routing / sent-copy will land in separate PRs.

[rubenhensen]

/dobby make the follow up PRs

[dobby-coder]

Dobby is on it! Dobby will pick up the follow-up test PRs from the plan — crypto-popup, encryption-flow, decryption-flow, message-routing, and sent-copy — and ship each as its own draft PR, building on the harness already merged. Dobby is so eager to make the test suite real, sir!

[dobby-coder]

Follow-up PRs from the plan are up, all draft pending review:

• tests: extract runtime message dispatcher + implement message-routing.test.ts #111 — message-routing: extract dispatchRuntimeMessage + 14 tests (-11 todos)
• tests: extract onAfterSend + implement sent-copy.test.ts #112 — sent-copy: extract handleAfterSend + 9 tests (-8 todos)
• tests: extract pure handleBeforeSend helpers + implement encryption-flow.test.ts #113 — encryption-flow: extract serializeRecipients / buildThreadingHeaders / evaluateBeforeSendGuards + 19 tests (-18 todos)
• tests: extract pure handleDecryptMessage helpers + implement decryption-flow.test.ts #114 — decryption-flow: extract chooseDecryptionInput / pickRecipientEmail / buildDecryptedThreadingHeaders / classifyDecryptionError / badgesFromSender + 19 tests (-19 todos)
• tests: extract buildRecipients + partial implementation of crypto-popup.test.ts #115 — crypto-popup: extract buildRecipients + 5 tests (-4 todos)

Combined: +66 passing, -60 todos. Once all merge the suite is 87 passing / 48 todo (from the post-#110 baseline of 52 passing / 82 todo, originally 21 / 108).

The 48 remaining todos all sit inside two closures: handleBeforeSend's keepAlive body (error-recovery + attachment-handling integration paths, 4 todos) and the popup's handleEncrypt / handleDecrypt (18 todos including init/DOM/auto-close). Closing them out is a heavier refactor — extracting the closures themselves behind injected pg-js / popup / runtime deps — and is best handled as a separate change rather than bundled into a test-only PR. Happy to take that on next if you want, or to break it up further.

No production behavior changes in any of these PRs; the extractions are pure relocations of existing logic with all current call sites rerouted.