Document TKO's testing coverage bar (real browsers only)#331
Conversation
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 23 minutes and 8 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
Updates contributor guidance in AGENTS.md to codify TKO’s testing coverage policy, emphasizing real-browser fidelity and discouraging partial-DOM environments for this DOM-binding framework.
Changes:
- Expands the Testing section with an explicit “coverage bar” policy (real browsers, no partial DOM, no excluding files).
- Documents rationale and links to closed PR #330 as a worked example.
- Adds a suggested approach for faster local feedback (run a narrower subset rather than lowering fidelity).
| 1. **Every spec runs in every supported real browser** (chromium, firefox, | ||
| webkit). The CI matrix is load-bearing. Do not consolidate it to a single | ||
| browser for speed. |
There was a problem hiding this comment.
The new policy states tests must run across Chromium/Firefox/WebKit, but earlier in this same Testing section the runner is described as "headless Chromium". Given vitest.config.ts supports multiple browsers via VITEST_BROWSERS and CI runs a 3-browser matrix, this wording is now inconsistent and may mislead contributors. Consider updating the runner description (and/or calling out that local default is Chromium, CI runs the full matrix).
TKO is a low-level DOM binding framework shipped to unknown downstream apps, and the dark-factory thesis makes the test suite the safety net in a way human review used to be. That raises the bar above the usual "enough for a product" level. Three concrete rules: 1. Every spec runs in every supported real browser (chromium, firefox, webkit). CI matrix is load-bearing — don't consolidate for speed. 2. No partial-DOM environments (happy-dom, jsdom, linkedom). Exactly the behaviors TKO most needs to verify — form-control event ordering, MutationObserver timing, namespaced attributes, custom elements — are where partial DOMs diverge from real browsers. A green there can mask a real-browser regression. 3. Excluding files from a run is a red flag. A file that would fail in some environment is a file testing something important; skipping doesn't save coverage, it concentrates risk. Reference: closed PR #330 worked through this trade and concluded the speed-for-correctness swap doesn't hold at TKO's level. Documenting so future agents don't re-propose the same pattern. For fast local feedback: scope the run (bunx vitest run packages/observable) rather than reducing fidelity of the full run. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
brianmhunt
force-pushed
the
docs/testing-coverage-bar
branch
from
b82d383 to
958451f
Compare
|
Closing — I misunderstood the intent. The goal of happy-dom/node isn't to replace browser testing for speed, it's to add coverage for non-browser runtimes TKO should support (TUI, SSR, server-side reactivity). Will redo as additive coverage, not a swap. Leaving the closed-PR reference intact for context. |
Summary
Codifies the coverage policy for TKO in AGENTS.md, under the existing Testing section. Motivated by the closed PR #330 — I proposed a happy-dom split for speed, and the trade didn't hold up for a library at TKO's level. Filing the reasoning so future agents don't re-propose the same pattern.
The policy
TKO is a low-level DOM binding framework published to npm and used by unknown downstream apps. The dark-factory thesis (small teams + AI assistance maintaining a framework) puts the test suite in the role humans used to play. So the coverage bar is higher than typical.
Three concrete rules:
Also points at PR #330 as a worked example so the rationale is traceable.
Test plan
Docs-only. No code changes.
🤖 Generated with Claude Code