Content
View differences
Updated by Alexander Coles 6 days ago
## Context
`frontend/src/app/features/work-packages/components/wp-fast-table` (59 files, ~6,200 lines) has one Vitest spec. Every module takes an Angular `Injector` and pulls its collaborators through `@LazyInject`, so no spec could construct a real `WorkPackageTable`; the one existing spec duck-types the table and subclasses a render pass to reach a protected method. End-to-end coverage exists only as ~60 Capybara specs.
The table is due to adopt the framework-agnostic batch selection model from #AGILE-361 (https://github.com/opf/openproject/pull/24525). That migration touches five event handlers and both places that paint the selected state, so it needs fast, table-level coverage first.
## Goal
A reusable spec harness that builds a real `WorkPackageTable` with its `TableHandlerRegistry` attached over a TestBed injector: real `IsolatedQuerySpace` and `WorkPackageView*` services, fakes for API, HAL, schema and routing. Specs feed rows through the production path (`querySpace.results` + `initialized`) and assert on the table's table's own interface: rendered rows, selection service state, `-checked`/`-pressed` paint, emitted outputs.
First consumers: a render spec and a row-click spec pinning plain, Shift and Ctrl/Cmd selection as it behaves today, so the migration can change it deliberately.
## Notes
* Found while reading: `WorkPackageViewSelectionService#selectionCount` counts keys of `selected`, so a toggled-off row still counts. Follow-up, not fixed here.
### Hints for QA
No production changes. Can be closed after merge.
`frontend/src/app/features/work-packages/components/wp-fast-table` (59 files, ~6,200 lines) has one Vitest spec. Every module takes an Angular `Injector` and pulls its collaborators through `@LazyInject`, so no spec could construct a real `WorkPackageTable`; the one existing spec duck-types the table and subclasses a render pass to reach a protected method. End-to-end coverage exists only as ~60 Capybara specs.
The table is due to adopt the framework-agnostic batch selection model from #AGILE-361 (https://github.com/opf/openproject/pull/24525). That migration touches five event handlers and both places that paint the selected state, so it needs fast, table-level coverage first.
## Goal
A reusable spec harness that builds a real `WorkPackageTable` with its `TableHandlerRegistry` attached over a TestBed injector: real `IsolatedQuerySpace` and `WorkPackageView*` services, fakes for API, HAL, schema and routing. Specs feed rows through the production path (`querySpace.results` + `initialized`) and assert on the table's
First consumers: a render spec and a row-click spec pinning plain, Shift and Ctrl/Cmd selection as it behaves today, so the migration can change it deliberately.
## Notes
* Found while reading: `WorkPackageViewSelectionService#selectionCount` counts keys of `selected`, so a toggled-off row still counts. Follow-up, not fixed here.
### Hints for QA
No production changes. Can be closed after merge.