<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/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=278964&issueIid=625161) </details> <!--IssueSummary end--> ## Summary Part of epic [Expand MSW test harness across all stages](https://gitlab.com/groups/gitlab-org/plan-stage/-/work_items/489). [MSW integration tests](https://docs.gitlab.com/development/testing_guide/#msw-integration-tests) replace Capybara feature specs with fast, MSW-backed Jest tests (no browser, \~20x faster) for full-scale single-mount Vue apps. Verify is a Phase 1 target because the Pipeline Editor and CI/CD Catalog are among the largest true Vue SPAs. This work item scopes which Verify `spec/features/` files are worth migrating. A spec migrates cleanly only when it asserts rendered DOM driven by a mockable GraphQL/REST response. Specs that assert backend model state, use Sidekiq/services/real Git, or check HTTP status/headers stay in Capybara. ## Playbook The full flow for migrating one spec, step 1 to last: 1. **Load the agent skill.** Point your agent at the [MSW migration skill](https://gitlab.com/fredericcaplette/agent-skills/-/tree/main/gitlab-msw-integration-tests?ref_type=heads); it carries the handler/fixture/variant conventions. 2. **Read the docs.** Skim the [MSW integration test docs](https://docs.gitlab.com/development/testing_guide/frontend_testing/#msw-integration-tests) so you know the harness layout before touching it. 3. **Pick a candidate.** Choose a spec (or a subset of `it` blocks) from the lists below. 4. **Write the MSW test.** Follow the skill: reuse an existing domain dir if one fits, otherwise add handlers/fixtures/variants per the conventions. 5. **Remove the migrated Capybara examples.** 6. **Check coverage parity.** Every removed Capybara `it` maps to either an equivalent MSW `it`, or an explicit line in the MR saying why it moved (backend-state check → request spec) or was dropped (redundant). Fewer tests with no explanation is a red flag — "the suite is green" is not evidence if it has 4 fewer tests. 7. **Open the MR.** Include a small table: before median / after median / example count before → after, plus the coverage-parity mapping. 8. **Add a scoped label.** Every migration MR should have `msw::migration` for easier tracking of this effort and to allow us to benchmark the speed diff. If the MR is purely harness work — fixture framework, handlers, CI, docs — use `msw::tooling` instead; the two are mutually exclusive. ### Successful migrations - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243364 — Migrate emoji award reactions to MSW (the original) - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/250833 — Migrate assignee, author, milestone and release filters to MSW - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249747 — Migrate my-reaction, confidential and search filters to MSW - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/249113 — Migrate work items list label filtering to MSW ### Top candidates These seem like perfect candidate that don't rely benefit from the capybara layer, and that moving to MSW could make significantly faster, and remove the risk of flakiness. - `spec/features/projects/ci/editor_spec.rb` -\> Pipeline Editor, single-mount SPA; most examples are pure `ciConfig`/lint renders. :white_check_mark: - `ee/spec/features/projects/pipelines/user_sees_security_tab_spec.rb` -\> security findings tab, fully render plus client pagination. :white_check_mark: - `spec/features/ci/catalog/catalog_releases_spec.rb` -\> Catalog SPA; version/list render cases. :white_check_mark: - `spec/features/ci/catalog/catalog_details_spec.rb` -\> Catalog SPA; readme/detail render. :white_check_mark: ### Partial candidates These have definitely some tests in there that migrating over would be well worth it, but not all. - `spec/features/projects/pipelines/pipeline_spec.rb` -\> details page; header/graph/badge/tab renders migrate, cancel/retry/play/delete stay. - `ee/spec/features/projects/pipelines/pipeline_spec.rb` -\> same, plus SaaS/licensed cases stay. - `spec/features/projects/pipelines/pipelines_spec.rb` -\> list renders migrate, create/cancel flows stay. ### Candidates that have been recently flagged as flaky tests - `spec/features/admin/admin_jobs_spec.rb` :white_check_mark: - `spec/features/projects/jobs/user_browses_job_spec.rb` - `ee/spec/features/profiles/usage_quotas/usage_quotas_spec.rb` :white_check_mark: - `ee/spec/features/projects/settings/pipeline_subscriptions_spec.rb` :white_check_mark: ### Reframe: assert the UI, not the backend These looked like skips because they assert DB state (pipeline counts, persisted records), but the same user action produces a real UI change we could assert instead. Drop the model-state check, mock the mutation response, and verify the rendered consequence. - `ee/spec/features/projects/pipelines/pipelines_spec.rb` -\> the identity-verification prompt appearing/disappearing is UI; only the `Ci::Pipeline.count` check is backend. Keep the arkose/phone flow in Capybara. - `spec/features/projects/pipeline_schedules_spec.rb` -\> create/edit/delete/take-ownership all re-render the schedules list (row added/removed, owner link changes). Assert the list, not the DB row. - `spec/features/ci/catalog/catalog_settings_spec.rb` -\> marking/removing a resource flips the "(unpublished)" badge and the catalog list entry. The `does not destroy existing releases` case stays (pure backend). ### Skip These seemed like high effort and or coupled to HAML/Rails. Feel free to disagree! - `spec/features/projects/settings/pipelines_settings_spec.rb` -\> HAML settings, form round-trips. - `spec/features/projects/badges/pipeline_badge_spec.rb` -\> SVG served by controller. - `ee/spec/features/projects/pipelines/pipeline_csp_spec.rb` -\> asserts CSP response header. - `spec/features/projects/blobs/user_views_pipeline_editor_button_spec.rb` -\> HAML blob page gated on Git/permissions. ### References - MSW integration test docs: https://docs.gitlab.com/development/testing_guide/#msw-integration-tests - Agent skill for migrating: https://gitlab.com/fredericcaplette/agent-skills/-/tree/main/gitlab-msw-integration-tests?ref_type=heads