-
Notifications
You must be signed in to change notification settings - Fork 553
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
Create a STANDARD_RESPONSES file for common issues #340
Comments
Where do I add the |
@onebree I do believe it goes in the root of your project where your |
@onebree see above
|
@bf4 I think the latter explanation "Autoload config from .simplecov is present" is pretty broad, that leaves open his interpretation of "should it go in |
@envygeeks duly noted, and thanks so much for your involvement in the comments here. Would you like me to ask @colszowka to add you as a commiter? |
@bf4 I'd love to help out if you guys are looking for people to help out. We use Simplecov so much maybe I can finally give back by helping you guys. |
@envygeeks My policy is to (ask to) invite anyone who seems interested in the library and makes quality contributions (code, comments, whatever). @colszowka would you add @envygeeks as a collab? |
I just got back to working on simplecov for our app. After creating BTW, we run our tests using Thank you for all the help, guys. |
@onebree Are you having a problem? The |
@bf4 By |
@colszowka would you add @envygeeks as a collab? |
I don't have a chance to open a PR (and not sure where it would fit), but in order to get things all playing nice with minitest/autorun and Guard on a non-rails project, I did the following: require "simplecov"
SimpleCov.at_exit {}
gem "minitest" # ensures you"re using the gem, and not the built in MT
require "minitest/autorun"
Minitest.after_run { SimpleCov.result.format! } This is due to how |
@pnomolos you may also want to take a look at some work I did in rubygems/rubygems.org#1028 |
Notes for some common issues I want to link to Coverage not what expected
Configuration |
Nice issue, great idea! I think we should also state, somehow/somewhere, that code being dynamically evaluated via |
Hey, all, if you're unexpectedly getting zero coverage, look at your `test/test_helper.rb' (or equivalent for RSpec, etc). When developing a Gem (let's call it require 'the_gem' near the end of my 'test/test_helper.rb' file, and I was getting zero coverage. Removing that line brought my line counts and coverage % back to correct values. Simple mistake to make, and you'll be scratching your head for ages if this doesn't just occur to you. |
This should all end up in the documentation, there's a trouble shooting section there arleady so we can see what to add from here :) |
From a comment I wrote in #235
This PR is for you:
If anyone wants to help put together a 'standard response' doc, that would be great. See e.g. the one nokogiri uses https://github.com/sparklemotion/nokogiri/blob/master/STANDARD_RESPONSES.md
Where coverage comes from
So, first, background on how simplecov gets coverage.
SimpleCov uses the stdlib Coverage module.
The Coverage module, when active, tracks when code is evaluated for the first time (i.e. when loaded or run )
SimpleCov starts and stops tracking coverage (via Coverage) when you run
SimpleCov.start
andSimpleCov.result
, respectively.Thus, when you run
SimpleCov.start
, load/require a file/files, then runSimpleCov.result
(which by default runs via an exit hook when your code finishes running), you will see a certain amount of 'code coverage'. That is, simply loading or requiring a Ruby file will result in some 'code coverage'. If you were to load all files in your app, then run SimpleCov.start, then run your tests, you would only capture the additional coverage for code that is executed for the first time. Likewise, if you ran SimpleCov.start, then loaded all files in your app, then ran the tests, even non-tested files would show 'coverage' as they will have code executed simple by being loaded/required.Where
SimpleCov.start
should happenAs described above, as early as possible; it must be before any app code is run.
When you
require 'simplecov'
, the.simplecov
file, if present, will be executed.Thus, if you, perhaps through
Bundle.require
require simplecov, but do not have a.simplecov
file, coverage will not start until you explicitly runSimpleCov.start
. In other words, by using a.simplecov
file, you ensure that SimpleCov will start as soon as it is required.The
.simplecov
https://github.com/colszowka/simplecov/blob/master/lib/simplecov/defaults.rb#L85
Common Problems
rake
often gives erroneous coverage because the app is loaded beforeSimpleCov.start
is run in a test helper.Rails and Railties
Vanilla Rails will evaluate all Railties before initializing the Rails app and its initializers. Thus, a Railtie is a reasonable way to hook into Rails initialization lifecycle to start SimpleCov before app code is run.
Right now,
require 'simplecov/railtie'
loads the fileWhat should now be obvious is that this railtie does not
require 'simplecov'
nor does it callSimpleCov.start
. @envygeeks is correct that missing the require is really a bug. (but checking the Rails env isn't necessary, because presumably you are only requiring simplecov in test or whenever you want to run it.)and to get around where you put the
SimpleCov.start
in your code is why I consider using a.simplecov
file a best practice.Parallel testing
Using .simplecov rather than separately requiring SimpleCov multiple times is recommended if you are merging multiple test frameworks like Cucumber and RSpec that rely on each other, as invoking SimpleCov multiple times can cause coverage information to be lost.
You'll also want to use multiple 'command_names' to differentiate reports being merged in together.
See https://github.com/colszowka/simplecov/blob/master/lib/simplecov/command_guesser.rb#L19 that sets an unset
command_name
from the env ifENV['PARALLEL_TEST_GROUPS'] && ENV['TEST_ENV_NUMBER']
, or from the command that ran the tests, or from any defined constants. to be sure, you may want to set it yourself, e.g.command_name "rails_app_#{$$}" # $$ is the processid
And then add something like
merge_timeout 3600 # 1 hour should cover how long it takes the tests to run
Example
.simplecov
or even define your own profile that is backwards compatible
The text was updated successfully, but these errors were encountered: