How Telepathy is tested
Methodology updated 14 July 2026
A test claim is useful only when it names the surface, environment and assertion. Telepathy does not convert a passing unit suite into a claim that every streaming site or production network is verified.
Evidence levels
| Level | What it can establish | What it cannot establish |
|---|---|---|
| Static review | Syntax, protocol agreement, input validation, cleanup paths, configuration and code-level failure scenarios. | Actual Chrome lifecycle, third-party player behavior or production routing. |
| Unit test | Isolated formatting, state and validation behavior under controlled inputs. | Network, storage, browser or permission integration. |
| Service E2E | Integrated service behavior for defined synchronization, access-control and persistence scenarios. | Production traffic, every load pattern or third-party player behavior. |
| Browser harness | Actual Chromium extension behavior, room/chat flow, declared regression paths and automated WCAG A/AA rules on named visible states. | Universal compatibility, screen-reader quality, cognitive usability or every dynamic UI state. |
| Real-site manual run | A dated result for a named site, Chrome build, account state and media page. | Future site versions, other regions, accounts, ads or DRM variants. |
Verification surfaces
- Automated suites cover validation, access control, synchronization, persistence and error handling under controlled conditions.
- Integrated scenarios exercise room creation, joining, playback coordination, chat, reactions, authentication, recovery and bounded operational history.
- Chromium checks exercise critical extension journeys and player-control behavior on controlled pages.
- An automated Chromium accessibility gate covers public pages and critical extension states across desktop and mobile viewports. It supplements, but does not replace, keyboard and assistive-technology review.
- Release checks cover configuration, packaging, backup/recovery behavior and version consistency.
Release gate
- Run syntax, unit and deterministic service suites in an isolated workspace.
- Use explicitly designated disposable services; never point destructive tests at production.
- Validate recovery and failure paths, not only the happy path.
- Run the automated accessibility gate, then complete keyboard and assistive-technology review for changed user journeys.
- Test the packaged extension in Chrome across create/join/chat/play/pause/seek, permission grant, reconnect and cleanup journeys.
- Record real-site tests separately by domain, date and observed limitation.
- Compare package, website, privacy policy and release version before publishing.
Test-data safety: data-writing tests are restricted to explicitly designated disposable environments and fail closed when that isolation cannot be verified.
Current-results rule: exact pass counts belong in a dated build record or CI run, not in evergreen marketing copy. The public version history describes shipped behavior; it does not imply every repository test ran against the live service.
Known blind spots
Compatibility can vary with browser policies, embedded players, DRM, advertisements, account state, region and provider changes. Production resilience, changed user journeys, screen-reader output and cognitive usability receive separate operational or human review. A result is marked conditional when credentials, region, paid content or production infrastructure are unavailable.