Content
View differences
Updated by Alexander Coles 14 days ago
## Context
The `frontend/src/turbo/` layer glues Turbo Drive and Angular together but had almost no unit coverage — the only spec was `helpers.spec.ts` (progress bar). Every integration function (`addTurboEventListeners`, `addTurboGlobalListeners`, the `register*StreamAction` functions, the Angular wrapper) hard-bound to the global `document` and returned `void`, giving vitest no way to drive them or tear listeners down between cases. The only coverage of real navigation behaviour was one expensive Selenium spec (`spec/features/notifications/turbo_angular_navigation_spec.rb`). The most upgrade-fragile code in the frontend therefore had the least coverage.
The sharpest symptom was `frontend/src/turbo/turbo-navigation-patch.ts`: a monkeypatch of Turbo internals (`FrameElement.delegateConstructor.prototype.proposeVisitIfNavigatedWithAction`) working around https://github.com/hotwired/turbo/issues/1300. It carried `@ts-nocheck` and `/* eslint-disable */`, so neither tsc nor eslint watched it, and it had zero tests — yet it runs on every frame-with-action visit. The patched symbol still exists in Turbo 8.0.23, so the patch still binds and is still load-bearing; it could not be safely deleted without a spec that reproduces the underlying symptom.
## Goal
Add unit test coverage across `frontend/src/turbo/`, then use it to settle whether the navigation monkeypatch is still needed.
## Notes
Relates to #DREAM-514 — this jsdom test harness is the precondition for the bootstrapping/routing rework that ticket is on hold over. Landing it improves the integration's testability without committing to the contentious redesign.
### Hints for QA
Changes are DX-focused. Does not need manual QA.
The `frontend/src/turbo/` layer glues Turbo Drive and Angular together but had almost no unit coverage — the only spec was `helpers.spec.ts` (progress bar). Every integration function (`addTurboEventListeners`, `addTurboGlobalListeners`, the `register*StreamAction` functions, the Angular wrapper) hard-bound to the global `document` and returned `void`, giving vitest no way to drive them or tear listeners down between cases. The only coverage of real navigation behaviour was one expensive Selenium spec (`spec/features/notifications/turbo_angular_navigation_spec.rb`). The most upgrade-fragile code in the frontend therefore had the least coverage.
The sharpest symptom was `frontend/src/turbo/turbo-navigation-patch.ts`: a monkeypatch of Turbo internals (`FrameElement.delegateConstructor.prototype.proposeVisitIfNavigatedWithAction`) working around https://github.com/hotwired/turbo/issues/1300. It carried `@ts-nocheck` and `/* eslint-disable */`, so neither tsc nor eslint watched it, and it had zero tests — yet it runs on every frame-with-action visit. The patched symbol still exists in Turbo 8.0.23, so the patch still binds and is still load-bearing; it could not be safely deleted without a spec that reproduces the underlying symptom.
## Goal
Add unit test coverage across `frontend/src/turbo/`, then use it to settle whether the navigation monkeypatch is still needed.
## Notes
Relates to #DREAM-514 — this jsdom test harness is the precondition for the bootstrapping/routing rework that ticket is on hold over. Landing it improves the integration's testability without committing to the contentious redesign.
### Hints for QA
Changes are DX-focused. Does not need manual QA.