Add RSpecRails/HttpStatusNameConsistency cop

[taketo1113]

Background

In Rack 3.1, several HTTP status symbol names were changed.
For example, the HTTP status 422 was renamed from :unprocessable_entity to :unprocessable_content.

• Update HTTP status codes and associated symbols rack/rack#2137

To align with these changes in Rack, the scaffold and scaffold_controller generators in the rspec-rails gem have also been updated to use :unprocessable_content instead of :unprocessable_entity, as shown below:

• Fix deprecation warning for :unprocessable_entity in scaffold-generated tests with Rack 3.2 rspec/rspec-rails#2860

  describe "POST /create" do
...
    context "with invalid parameters" do
...
      it "renders a response with 422 status (i.e. to display the 'new' template)" do
        post posts_url, params: { post: invalid_attributes }
-        expect(response).to have_http_status(:unprocessable_entity)
+        expect(response).to have_http_status(:unprocessable_content)
      end
    end
  end

Details

This Pull Request adds a new cop that detects the use of obsolete HTTP status symbols in existing test code and enforces consistency by using the current HTTP status names.
The cop checks for symbols defined in Rack::Utils::OBSOLETE_SYMBOL_MAPPINGS, which currently include :payload_too_large and :unprocessable_entity.
https://github.com/rack/rack/blob/v3.1.0/lib/rack/utils.rb#L573-L576

Additional Information

The rubocop-rails gem has also introduced a similar cop named Rails/HttpStatusNameConsistency,
which enforces consistency by using the current HTTP status names in app/controllers/*.

• Add Rails/HttpStatusNameConsistency cop rubocop-rails#1520

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have created a new cop:

• Added the new cop to config/default.yml.
• The cop is configured as Enabled: pending in config/default.yml.
• The cop documents examples of good and bad code.
• The tests assert both that bad code is reported and that good code is not reported.
• Set VersionAdded: "<<next>>" in default/config.yml.

If you have modified an existing cop's configuration options:

• Set VersionChanged: "<<next>>" in config/default.yml.

[pirj]

Thanks for the contribution. In your PR to rspec-rails there’s this hinting that there will be a warning.

Do you feel that the cop is needed when there’s a deprecation warning?
For autocorrecting?
I’m on the fence if this a goal or a non-goal for us.

[taketo1113]

@pirj Thank you for the comment.

I think the cop is needed for autocorrecting.
While newly generated files from the rspec-rails gem do not produce any warnings, it would be useful for fixing existing obsolete HTTP status symbols.

(I fixed the CI error by confirming the configuration and documentation.)

[pirj]

Thank you!

[pirj]

Wow, today I learned.

[taketo1113]

I also learned about it here: rubocop/rubocop-rails#1520 (comment)

It's very convenient!
https://docs.rubocop.org/rubocop/development.html#requiring-a-gem

[ydah]

Wow, that's so nice.

[ydah]

Thank you for your contribution!❤️

[ydah]

Wow, that's so nice.