Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update coverage #1905

Merged
merged 7 commits into from
Mar 18, 2015
Merged

Update coverage #1905

merged 7 commits into from
Mar 18, 2015

Conversation

myronmarston
Copy link
Member

I recently learned that # :nocov: can be used to tag a chunk of code so simplecov doesn't consider it. Before learning that, I never bothered to try to get our coverage up because we have so many places where we do alternate method implementations for certain versions of ruby or for windows or whatever. With # :nocov:, it's trivial to tag those so that we can actually meaningfully consider coverage.

I've written a bit about my test coverage philosophy in the past. Besides all the alternate method implementations, keeping coverage up for RSpec's actually not hard, and I think we get enough value out of it to enforce it. I've seen a couple PRs from contributors where they added tests but because of how it was written it wasn't even executing the implementation it was intended to. Enforcing coverage will cause our travis build to catch such things for us.

In this PR, I've gotten coverage up to 100% and configured simplecov to enforce it on our "main" builds (travis builds for MRI >= 2.0), and I've stopped loading simplecov for other builds. The uncovered code generally fell into 3 categories:

  • Dead code that can be deleted. There was a fair bit of it. Often it's private methods that aren't called but in some cases it was logically unreachable code and/or conditional code in a private method that would only be hit if a caller passed a certain arg that none of the callers pass.
  • Code that's not for MRI >= 2.0. I just tagged it with # :nocov:.
  • Code that can and should be covered by a test. In one case (ad53e7f), the act of trying to add coverage showed me that there was a long-standing bug.

Ideally, I'd like to see this same treatment done for expectations/mocks/support. Anyone want to take that on?

/cc @rspec/rspec

`system` returns a boolean value to indicate success/failure,
but the use of `failure_message` was in a `rescue` block that
never got executed.  It appears this has been broken since
ea70e4e. Before that commit,
we used `Rake::FileUtilsExt#ruby`, which does indicate failure
by raising an error (and thus the `rescue` was correct). In
ea70e4e, we switched to using
`system` and the rescue was left in place but never got hit
anymore.

The lack of test coverage here is why we never noticed, so I
addressed that as well.
`RSpec::CallerFilter.first_non_rspec_line` either
returns the line or raises an error, so the branch
for when `line` is nil could never be reached.
@myronmarston
Copy link
Member Author

As it turns out, we need to skip simplecov on MRI 2.0 as well. It's just 2.1 and 2.2 that run it.

@xaviershay
Copy link
Member

LGTM, left a couple of non-blocking comments.

myronmarston added a commit that referenced this pull request Mar 18, 2015
@myronmarston myronmarston merged commit b6d9a8e into master Mar 18, 2015
@myronmarston myronmarston deleted the update-coverage branch March 18, 2015 16:56
@soulcutter
Copy link
Member

This is awesome! Well done

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.

7 participants