Skip to content

[DREAM-906] Pass test_selector as a system argument to ViewComponents - #26001

Draft
myabc wants to merge 4 commits into
devfrom
code-maintenance/dream-906-test-selector-system-argument
Draft

myabc wants to merge 4 commits into
devfrom
code-maintenance/dream-906-test-selector-system-argument

Conversation

@myabc

@myabc myabc commented Oct 13, 2026 •

Copy link
Copy Markdown
Contributor

Ticket

https://community.openproject.org/wp/DREAM-906

What are you trying to accomplish?

Primer's test_selector: system argument renders data-test-selector only outside production. Many callers pass the selector through data: { test_selector: } or data: { "test-selector": } instead, which bypasses that and ships the attribute in production HTML.

Converts the 199 such usages that sit on component constructors, slots and flex_layout to the system argument. Outside production the rendered HTML is unchanged, so no spec selector changes.

What approach did you choose and why?

The conversion is the autocorrect output of a new cop, OpenProject/TestSelectorSystemArgument, proposed in opf/rubocop-openproject#12. RuboCop applies it to Ruby files and erb_lint's RuboCop bridge to templates. Enabling the cop here follows in a further commit once that gem version is released; until then this PR stays a draft.

Two places read the attribute at runtime and are changed first, in their own commits:

  • The drag-and-drop container accessor of the inactive attributes list in the type form configuration pointed at [data-test-selector=…]. It now uses the list's existing class.
  • Shares::PermissionButtonComponent derived its Turbo Stream wrapper key from data[:"test-selector"]. It now reads the test_selector system argument, which is present in every environment; only its rendering is limited to non-production.

Deliberately left as they are:

  • Primer form controls (Primer::Alpha::TextField, TextArea, CheckBox, RadioButton, Select, form DSL inputs such as select_list, and slots that build inputs). They do not honour test_selector: and render it as a literal test_selector="…" attribute. This was checked by rendering each affected component and slot shape both ways and comparing which element carries the attribute; all other shapes put it on the same element either way.
  • Rails helpers and plain tags (component_wrapper, link_to, content_tag, primer_form_with, …), where no system argument exists.
  • menu_options in SortHelper, which merges a top-level data: into content_arguments, so a top-level test_selector: would land on a different element.

Not covered by CI: 39 of the converted selectors are not referenced by any spec. Their call shapes are among those rendered and compared as described above.

AI involvement

Merge checklist

  • Added/updated tests
  • Added/updated documentation in Lookbook (patterns, previews, etc)
  • Tested major browsers (Chrome, Firefox, Edge, ...)

myabc added 3 commits October 13, 2026 16:25
Points the drag-and-drop container accessor at the list's class
instead of its data-test-selector attribute, which is not meant to
be rendered in production.

https://community.openproject.org/wp/DREAM-906
Makes PermissionButtonComponent derive its wrapper key from the
test_selector system argument instead of the data attribute, and
passes the selector that way from all four callers.

https://community.openproject.org/wp/DREAM-906
Applies the TestSelectorSystemArgument autocorrect: component
constructors, slots and flex_layout receive test_selector: instead
of a data-test-selector data attribute, so the attribute is no
longer rendered in production. Primer form controls keep the data
attribute, because they render the system argument literally.

https://community.openproject.org/wp/DREAM-906
@github-actions

Copy link
Copy Markdown
1 Warning
⚠️ @opf/dream-team Files in app/components/op_primer were modified:

  • app/components/op_primer/email_updates_mode_selector_component.html.erb
  • app/components/op_primer/quick_filter/select_panel_component.html.erb

Please review these changes to ensure they align with the design system guidelines.

Generated by 🚫 Danger

@github-actions

Copy link
Copy Markdown

Warning

Flaky specs

  • rspec ./modules/documents/spec/features/documents/project/show_edit_document_spec.rb[1:1]
  • rspec ./modules/overviews/spec/features/managing_dashboard_page_spec.rb[1:1:1]
  • rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]
🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #26001, linked for reference only):

- `rspec ./modules/documents/spec/features/documents/project/show_edit_document_spec.rb[1:1]`
- `rspec ./modules/overviews/spec/features/managing_dashboard_page_spec.rb[1:1:1]`
- `rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]`

Treat this as a standalone task, unrelated to PR #26001. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #26001 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

Runs erb_lint with autocorrect over the templates touched by this
branch and commits the result. Layout and quote style only, apart
from two ternaries with a nil branch in the PDF export styles
partial, which become if expressions.
@github-actions

Copy link
Copy Markdown

Warning

Flaky specs

  • rspec ./spec/features/types/form_configuration_query_spec.rb[1:1:8:1:1]
🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #26001, linked for reference only):

- `rspec ./spec/features/types/form_configuration_query_spec.rb[1:1:8:1:1]`

Treat this as a standalone task, unrelated to PR #26001. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #26001 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant