-
-
Notifications
You must be signed in to change notification settings - Fork 285
Description
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