Skip to content

Suggest usage of aggregate_failures directly in RSpec/MultipleExpectation error message #2131

@svgr-slth

Description

@svgr-slth

Is your feature request related to a problem? Please describe.

When encountering the RSpec/MultipleExpectation cop violation, developers often default to splitting specs into multiple examples to satisfy the "one expectation per example" rule, without realizing that aggregate_failures is a better alternative. I discovered the aggregate_failures option late in my refactoring process, which meant I had unnecessarily split many test cases that would have been better structured using aggregated failures. The problem is that the cop's error message doesn't educate users about aggregate_failures, so developers only learn about this option if they dig into the documentation. Since this cop is straightforward to "fix" by splitting specs, most users never consult the docs and miss out on a more appropriate solution.

Describe the solution you'd like

Enhance the RSpec/MultipleExpectation cop error message to proactively suggest using aggregate_failures as an alternative to splitting specs. Similar to other RuboCop messages that use "Prefer using..." or "Consider using..." language, this would educate developers at the point of encounter. For example, the error message could be:

Example has too many expectations [2/1]. Consider using `aggregate_failures` if these expectations are logically related, or split into separate examples.

This would:

  • Educate users about aggregate_failures when they first encounter the violation
  • Help them make informed decisions about whether to aggregate or split
  • Improve test suite structure by encouraging proper use of aggregate_failures
  • Save significant time by preventing unnecessary spec splitting and later refactoring

Describe alternatives you've considered

Not much here, maybe auto correction but this seems not viable since the cop can't determine whether expectations should be aggregated or split into separate examples

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions