Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cop idea: RSpecRails/RequestUrlHelper #6

Open
phil-workato opened this issue Oct 26, 2023 · 0 comments
Open

Cop idea: RSpecRails/RequestUrlHelper #6

phil-workato opened this issue Oct 26, 2023 · 0 comments
Labels

Comments

@phil-workato
Copy link

phil-workato commented Oct 26, 2023

Request specs:

provide a thin wrapper around Rails’ integration tests, and are designed to drive behavior through the full stack, including routing (provided by Rails)

One confirmation that the use of non-generated paths is preferred (with a single edge case exception) is in rspec-rails examples:

post "/widgets", :params => { :widget => {:name => "My Widget"} }, :headers => headers

Another is Rails testing guides:

post "/articles",
    params: { article: { title: "can create", body: "article successfully." } }

A common way is to use the path helpers:

expect {
  post widgets_path, params: {:widget => {:name => "My Widget"}}, :headers => headers
}.to change { ... }

Rails guides mention that:

[Generating Paths and URLs from Code] ... reduces the brittleness of your view

however, in specs it is the other way around. To keep the public API paths intact, you must use direct paths in request specs, or write additional routing specs.

Suggestion

Add a cop that would flag usages of path/URL helpers in request specs.

cc @koic WDYT?

@ydah ydah transferred this issue from rubocop/rubocop-rspec Mar 29, 2024
@ydah ydah added the cop label Mar 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants