Let me tell you a story about coverage reports lying to me.
Years ago, at a company with a huge Ruby codebase, I stared at green coverage numbers like a fool. “Coverage says yes, reality says no.” Controllers with ten services inside, one happy-path test, and everything technically covered. Meanwhile, bugs were popping up like popcorn in the background.
So I wrote a tiny linter. Just enough to point out the obvious: if you wrote a public method, you better have a test for it. And not just a test that runs the line — a test that actually checks behavior.
Fast forward a bit, I’m on my personal projects, doing vibe coding. That’s where AI writes the code and I review it. Fun, right? Until you realize the AI has very optimistic testing habits. It adds methods like it’s confetti, but forgets the tests. Or writes shallow ones. Or hits one branch and calls it a day.
I’ve had enough. Again. And again. And again. Four times to be exact. Finally, I thought, maybe I should just make this a gem. So here it is: rubocop-rspec_parity.
What it does (in plain human words)
Public methods are promises.
Tests are the proof.
Think of it like a little courtroom for your code. Your methods swear they’ll behave. Your tests show up to testify. And if there’s no testimony? The cop yells.
Here’s what it actually checks:
- Are your public methods actually tested? (No hiding behind “covered lines”)
- Are all branches tested?
if,else,||— nothing escapes - Did someone commit a “bug fix, no time to test” trick again? The cop knows
Basically, it’s your spec’s annoying little friend. Instant feedback, no excuses, no waiting for CI. It’s like a mirror for your code: you think it’s okay, until it tells you otherwise.
It doesn’t invent rules. It doesn’t force new conventions. It just makes sure you follow the ones you already claim to follow. If you believe tests matter, this gem is like that one coworker who won’t let you sneak out early — except way less passive-aggressive.
Who this is for
- Solo devs doing vibe coding who want AI output to be less… optimistic
- Ruby teams that care about test quality and want fast feedback
- Anyone who’s ever stared at coverage numbers and muttered, “sure… yeah… that counts”
Quick example
# bad
def do_stuff(x)
return true if x > 10
false
end
# no test for x <= 10 branch
# good
def do_stuff(x)
return true if x > 10
false
end
# tests cover both branches
See? Simple, obvious, yet people miss it all the time.
TL;DR
rubocop-rspec_parity is out. It’s new. It’s your spec’s nagging friend. It works. Drop it in your Gemfile, require it in .rubocop.yml, and your tests will start behaving like adults.
Public methods are promises.
Tests are the proof.
GitHub: https://github.com/povilasjurcys/rubocop-rspec_parity
Side note: yes, I had a tiny AI whispering ideas while I wrote this post. But I promise the coffee, the bugs, and the frustration are 100% human. ☕🐛
