## Summary This Epic targets to add feature specs for Saved views feature. ## Feature flags The feature is behind `work_item_planning_view`. ## References * Saved views feature epic - https://gitlab.com/groups/gitlab-org/-/work_items/20014 * Documentation - https://docs.gitlab.com/user/work_items/saved_views/ ## High level testing plan All of the tests will go under * `spec/features/work_items/list/user_manage_saved_views_list_spec.rb` * `ee/spec/features/work_items/list/user_manage_saved_views_list_spec.rb` | User actions | |--------------| | User creates a saved view | | Lists all the subscribed saved views | | List all the shared saved views in Browse modal | | User updates Saved view metadata | | User removes the saved view from the list | | User deletes the saved view | | User copies URL of the saved view | | member/Non-member opens the private saved view | | member/Non-member opens the shared saved view | | anonymous user opens the saved view | | Free tier User tries to add saved view | | Free tier User tries to open a shared saved view | ## Guidance for writing the tests ### Data Setup Rules 1. Use `let_it_be` for database records that tests do NOT mutate 2. Use `let_it_be_with_refind` for records that tests DO mutate 3. Use plain `let` ONLY for computed values or cheap objects 4. Use `before_all` for expensive setup shared across all examples (adding members, creating callouts) 5. Use `before` for per-example setup (sign_in, visit, stub_feature_flags) 6. NEVER stub feature flags in `before_all` - only in `before` ### Onboarding Modal Dismissal ALWAYS include this in `before_all` for any spec that visits work items pages: ```ruby before_all do create(:callout, user: user, feature_name: :work_items_onboarding_modal) end ``` Without this, the onboarding modal blocks all page interaction and tests will fail. ### Waiting for requests * Use `wait_for_all_requests` after every `visit` call * Use `wait_for_requests` after user interactions (clicks, form submissions) ### Element Selection * Prefer semantic Capybara methods: `click_button 'Edit'`, `fill_in 'Title'` * Use `within_testid('widget-name')` for scoping to specific widgets * Use `find_by_testid('element-name')` when needed * NEVER use CSS class selectors when a data-testid exists ### Assertions * Assert against what is visible on the page, NOT database state * Use `expect(page).to have_content(...)` or `have_link(...)` etc. * Use `:aggregate_failures` metadata when a test has multiple expectations * Use `be_axe_clean` for accessibility assertions where appropriate ### Anti-Patterns to AVOID * Do NOT create separate spec files per work item type (issue, task, epic) * Do NOT use `sleep` in tests * Do NOT write monolithic tests - keep each `it` block focused * Do NOT duplicate logic that exists in shared examples - use `it_behaves_like` * Do NOT combine multiple attribute states in a single test case * Do NOT add comments explaining obvious code * Do NOT over-engineer - keep tests simple and deterministic * Do NOT hard-code IDs - use factory-generated values * Do NOT assert database internals in feature specs ### Query Limiting If tests fail due to query limits, add: ```ruby allow(Gitlab::QueryLimiting::Transaction).to receive(:threshold).and_return(175) ``` Use the lowest threshold that passes. Typical ranges: 100-150 for simple pages, 200-300 for hierarchy operations. ### EE-Specific Rules For EE specs, additionally: * Add `stub_licensed_features(feature_name: true)` in `before` blocks * Use `close_work_item_feedback_popover_if_present` after visiting pages * Common licensed features: `issuable_health_status`, `iterations`, `epics`, `epic_colors`, `subepics` ### How to Run the Specs #### Run a single spec file ``` bundle exec rspec <file_path> ``` ``` bundle exec rspec ee/spec/features/work_items/list/saved_views/user_creates_saved_view_spec.rb ``` #### Run a specific test by line number ``` bundle exec rspec <file_path>:<line_number> ``` ``` bundle exec rspec spec/features/work_items/list/user_interacts_with_drawer_spec.rb:25 ``` #### Troubleshooting the specs - Add `WEBDRIVER_HEADLESS=0` before the command to run with a visible browser - Add [`binding.pry`](https://docs.gitlab.com/development/pry_debugging/#stepping) for pausing the specs and open rails console - Add [`live_debug`](https://docs.gitlab.com/development/testing_guide/best_practices/#live-debug) to pause the specs and open web version with the user details ## When using a AI prompts ### Add context ``` You are writing Ruby feature specs for the GitLab work items framework. Follow these rules strictly: Refer to existing specs before writing a new one. Follow the project structure - CE specs go in: `spec/features/` - EE specs go in: `ee/spec/features/` - Shared examples are in: `spec/support/shared_examples/features/` - Helpers are in: `spec/support/helpers/` ``` ### Add constraints ``` - Follow the exact patterns from the existing specs listed above - Reuse shared examples where they exist - do not rewrite them - Keep each it block focused on ONE behavior - Use deterministic test data (no random values, no time-sensitive dates) - Do not add comments to the code - Do not over-engineer - simple setup, simple assertions - Run the spec with: bundle exec rspec <file_path> - Do not install any new dependency unless asked ```