test: extract 3 modules from extension.ts + 38 new tests (194 → 232)#29
Conversation
Three thin extractions out of the activate() closure so the behaviour they encapsulate can be exercised in unit tests rather than waiting for the @vscode/test-electron integration run: - lspStart.ts: bounded-time client.start(). Internally restructured from Promise.race([start, timeout]) to a single deferred with a settled flag — Promise.race plus vitest's fake timers triggered "rejection handled asynchronously" warnings because Promise.race attaches its handler one microtask after the timer fires the rejection. The deferred avoids the two-promise dance. - middleware.ts: pure transformDiagnostics(uri, diagnostics, config) composing the disabledProviders blanket-drop and the severityThreshold filter. extension.ts now plumbs the config in via deps; the composition (which the user sees) is testable in isolation. - scanOnSave.ts: createScanOnSaveHandler(deps) returns a save handler that closes over a busy flag. Cheap-gates-first ordering (isEnabled → isPipelineFile → busy) is pinned; each handler instance has its own busy flag so two windows don't share a lock. CodeLens provider class gets four new tests pinning the lens range (line 0 col 0), the click target (pipelineCheck.findings.focus), the "reads live counts each call" contract (so a future cache-once-at- construction refactor trips), and the per-document scope (lens reflects only this document's diagnostics, not the workspace total). Tests breakdown: - lspStart: 12 tests (timeout race, stop-on-timeout, settled-flag, copy) - middleware: 13 tests (disabled stage, severity stage, composition) - scanOnSave: 9 tests (gates, busy guard, per-instance lock) - codeLens: +4 tests on the existing file Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ 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. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (8)
✨ 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 |
1 participant
Summary
Three thin extractions out of
activate()so the behaviour they encapsulate can be exercised in unit tests rather than waiting for the@vscode/test-electronintegration run, plus a few gaps in the existing CodeLens provider tests.Extractions
client.start()(was inline in extension.ts)Promise.race([start, timeout])to a single deferred with asettledflag —Promise.raceplus vitest's fake timers leakedPromiseRejectionHandledWarningbecause race attaches its handler one microtask after the timer rejectstransformDiagnostics(uri, diagnostics, config)— pure composition of disabledProviders blanket-drop + severityThreshold filtercreateScanOnSaveHandler(deps)— save handler with closure-scoped busy flagisEnabled → isPipelineFile → busy); per-instance busy flag so two windows don't share a lockextension.ts gets shorter at every site:
Test coverage (194 → 232, +38)
pipelineCheck.findings.focus, live count (not cached), per-document scopeTest plan
npm test— 232/232 vitest assertions passnpm run typecheck— cleannpm run lint— cleannpm run bundle:dev— bundle builds (808.5 kB, unchanged ±0.5 kB)🤖 Generated with Claude Code