Skip to content

Conversation

@kevinrobell-st
Copy link

Closes #2128

This is based on the Rails/Output cop with three minor changes.

  1. Autocorrection is removed as the expectation is that the print statement will be removed by the user.
  2. The message is changed.
  3. The cop runs only on spec files.

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 is configured as Enabled: true in .rubocop.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.

This is based on the `Rails/Output` cop with three minor changes.

1. Autocorrection is removed as the expectation is that the print
   statement will be removed by the user.
2. The message is changed.
3. The cop runs only on spec files.
@kevinrobell-st kevinrobell-st requested a review from a team as a code owner November 6, 2025 00:26
@kevinrobell-st
Copy link
Author

RSpec/Output was chosen as the cop name to align with Rails/Output but potentially it'd be better to have more descriptive name here.

@kevinrobell-st
Copy link
Author

I did some grepping around the real-world-rspec repo as well and I think this cop should be fine to add. There are some legitimate uses of printing in some integration tests, some examples of print statements that look like they were leftover from debugging and print statements in setup, helper and support logic. By making the cop enabled: pending for now we don't have to confront those changes immediately but there might come a time in the future were we decide to exclude more subdirectories or files from this cop or even mark it as enabled: false if there are too many false positives. I still think that it has value as a cop though because generally printing in specs is not expected.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

New cop to disallow printing from tests

1 participant