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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix coverage reporting for built-in bundles #3180

Merged
merged 1 commit into from Dec 7, 2014

Conversation

Projects
None yet
3 participants
@mattr-
Member

mattr- commented Dec 3, 2014

People can keep bundled gems in vendor/bundle or vendor/gems so let's exclude those so that simplecov reports better than 50% coverage 馃槂

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Dec 3, 2014

Member

What is the coverage now?

Member

parkr commented Dec 3, 2014

What is the coverage now?

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Dec 3, 2014

Member

I don't think we do much with code coverage anymore...

Member

parkr commented Dec 3, 2014

I don't think we do much with code coverage anymore...

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Dec 3, 2014

Member

85.97%

Code coverage is an essential tool for being able to refactor because it gives you an idea of what's covered by a test and what isn't, and what pieces of code you'll need to add tests for before being able to change it.

Member

mattr- commented Dec 3, 2014

85.97%

Code coverage is an essential tool for being able to refactor because it gives you an idea of what's covered by a test and what isn't, and what pieces of code you'll need to add tests for before being able to change it.

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Dec 3, 2014

Member

A percentage doesn't help much, though. This would be more useful if I could see quickly whether my PR is covered fully, not the whole codebase.

Member

parkr commented Dec 3, 2014

A percentage doesn't help much, though. This would be more useful if I could see quickly whether my PR is covered fully, not the whole codebase.

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Dec 3, 2014

Member

If you're interested in that metric, we could always try coveralls.

Member

mattr- commented Dec 3, 2014

If you're interested in that metric, we could always try coveralls.

@mattr-

This comment has been minimized.

Show comment
Hide comment
@mattr-

mattr- Dec 3, 2014

Member

but a simple open coverage/index.html also works, at least for me. 馃槂

Member

mattr- commented Dec 3, 2014

but a simple open coverage/index.html also works, at least for me. 馃槂

@parkr

This comment has been minimized.

Show comment
Hide comment
@parkr

parkr Dec 3, 2014

Member

We did try coveralls 鈥 it commented every time you pushed to a PR on that PR that the total code coverage had changed from x to y. Not super useful and it got noisy pretty quickly. I didn't like coveralls that much.

Maybe we disable it on travis?

Member

parkr commented Dec 3, 2014

We did try coveralls 鈥 it commented every time you pushed to a PR on that PR that the total code coverage had changed from x to y. Not super useful and it got noisy pretty quickly. I didn't like coveralls that much.

Maybe we disable it on travis?

@parkr parkr merged commit 253bcc2 into master Dec 7, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details

@parkr parkr deleted the fix-coverage-reporting branch Dec 7, 2014

parkr added a commit that referenced this pull request Dec 7, 2014

@jekyll jekyll locked and limited conversation to collaborators Feb 27, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.