<details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=65271576&issueIid=2273) </details> ## Summary Refactor `workitems_test.go` to replace large `t.Run()` style tests (where a single parent test runs many child tests with shared data setup) with individual, top-level parent test functions per scenario. ## Background Raised by [@PatrickRice](https://gitlab.com/PatrickRice) in [!2928](https://gitlab.com/gitlab-org/api/client-go/-/merge_requests/2928#note_3486596308): > I do think I probably want one more MR after this, personally, I'm _not_ a fan of large `t.Run()` style tests where a parent test runs a bunch of child tests with a bunch of data setup, so I'll likely create another `~"type::maintenance"` MR where I split the individual tests out into multiple parent test functions. Even with test setup helper functions, I find multiple parent tests _significantly_ easier to debug and maintain, and they work much better with VSCode (since you don't have to run the tests first to get the sub-tests to show up). ## What - Identify all large table-driven / `t.Run()` test blocks in `workitems_test.go` - Split each sub-test case into its own top-level `TestXxx` function - Extract shared setup logic into helper functions to avoid duplication - Ensure each test function calls `t.Parallel()` - Add Gherkin-style `// GIVEN / WHEN / THEN` comments inline per the project's test conventions ## Why - Individual parent test functions are significantly easier to debug — failures point directly to the failing function - VSCode (and other editors) can discover and run individual tests without needing a prior test run to populate sub-test names - Reduces cognitive overhead when reading and maintaining the test file ## Acceptance Criteria - [ ] No large `t.Run()` blocks remain in `workitems_test.go` where a single parent drives many unrelated scenarios - [ ] Each scenario has its own top-level `TestXxx` function - [ ] Shared setup is extracted into helper functions - [ ] All tests pass (`mise exec -- make test`) - [ ] Linting passes (`mise exec -- make lint`) ## Implementation plan *Added by [GitLab Duo Agent Platform 🤖](https://gitlab.com/components/agents-and-flows/quick-win-labeller)* 1. **Identify all `t.Run()` blocks** — Open `workitems_test.go` and locate every parent test function that uses a loop or slice of sub-test cases passed to `t.Run()`. 2. **Create individual `TestXxx` functions** — For each sub-test case, create a new top-level function named descriptively (e.g., `TestGetWorkItem_Success`, `TestGetWorkItem_NotFound`). 3. **Extract shared setup into helpers** — Move any repeated mock/client setup into small helper functions (e.g., `setupWorkItemsService(t)`) to keep each test concise and DRY. 4. **Add `t.Parallel()`** — Ensure every new top-level test function calls `t.Parallel()` at the start. 5. **Add Gherkin-style comments** — Annotate each test with `// GIVEN`, `// WHEN`, and `// THEN` inline comments following the project's existing conventions. 6. **Verify tests pass** — Run `mise exec -- make test` to confirm all tests pass. 7. **Verify linting passes** — Run `mise exec -- make lint` to confirm no linting issues are introduced.