You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello. 👋 I'm not sure if this is a bug or a feature request but opting to go with the latter. I'm hitting a situation, with pattern matching, where I don't think I necessarily want code coverage for the else branch when I've configured SimpleCov as follows:
I'm using pattern matching and monads for a functional design. Situations in which I'd hit the else branch is low because a monad can only be a Success or Failure. It's not impossible, only very rare to hit the else branch. As an added benefit of pattern matching -- should the else branch be hit -- I'll get a NoMatchingPatternError exception so I'll know immediately if this situation occurs. That last statement makes pattern matching unique versus a traditional case...when statement and why I'm bringing this issue up.
One workaround -- and the most obvious -- is to always implement the else branch:
My system shows ≈90%+ line coverage, but just ≈75% branch coverage. I was fairly surprised because I do test all significant branches, and those untested were mostly from generated boilerplate and weren't that important to test.
As it turns out, nearly all of those were from else branches in pattern matching
The thing is: we shouldn't care for an else branch for PM unless it's explicitly defined. A skilled developer would probably try and use PM with a comprehensive coverage – meaning there's no valid data that must be handled explicitly.
Writing tests for an absurd situation isn't particularly useful
Overview
Hello. 👋 I'm not sure if this is a bug or a feature request but opting to go with the latter. I'm hitting a situation, with pattern matching, where I don't think I necessarily want code coverage for the
else
branch when I've configured SimpleCov as follows:Consider the following code:
I'm using pattern matching and monads for a functional design. Situations in which I'd hit the
else
branch is low because a monad can only be aSuccess
orFailure
. It's not impossible, only very rare to hit theelse
branch. As an added benefit of pattern matching -- should theelse
branch be hit -- I'll get aNoMatchingPatternError
exception so I'll know immediately if this situation occurs. That last statement makes pattern matching unique versus a traditionalcase...when
statement and why I'm bringing this issue up.One workaround -- and the most obvious -- is to always implement the
else
branch:The other workaround is to ignore code coverage for the
else
branch entirely:The only problem with either of these workarounds is that all of this gets tedious quickly for minimum benefit. 😢
Screenshots/Screencasts
Here's a screenshot of the report as generated by SimpleCov:
Steps to Recreate
To recreate, run the following:
unzip demo.zip
.demo
.bundle install
bundle exec rspec
open coverage/index.html
Environment
The text was updated successfully, but these errors were encountered: