Key Features • Installation • Coverband Web UI • Advanced Config • Newer Features • License • Change Log / Roadmap • Code of Conduct
A gem to measure production code usage, showing a counter for the number of times each line of code is executed. Coverband allows easy configuration to collect and report on production code usage. It reports in the background via a thread, can be used as Rack middleware, or can be manually configured to meet any need.
Note: Coverband is not intended for test code coverage; for that we recommend using SimpleCov.
The primary goal of Coverband is to give you deep insight into the production runtime usage of your application code, while having the least impact on performance possible.
- Low performance overhead
- Simple setup and configuration
- Out of the box support for all standard code execution paths (web, cron, background jobs, rake tasks, etc)
- Splits code loading usage (Rails eager load) and runtime usage metrics
- Easy to understand actionable insights from the report
- Mountable web interface to easily share reports
Coverband stores coverage data in Redis. The Redis endpoint is looked for in this order:
ENV['COVERBAND_REDIS_URL']
ENV['REDIS_URL']
localhost:6379
The redis store can also be explicitly defined within the config/coverband.rb
. See advanced config.
Add this line to your application's Gemfile
, remember to bundle install
after updating:
gem 'coverband'
With older versions of Coverband, projects would report to redis using rack or sidekiq middleware. After Coverband 4.0, this should no longer be required and could cause performance issues. Reporting to redis is now automatically done within a background thread with no custom code needed.
See changelog.
The Railtie integration means you shouldn't need to do anything else other than ensure Coverband is required after Rails within your Gemfile.
For the best coverage, you want this loaded as early as possible. We recommend requiring cover band directly in the config.ru
. Requiring Coverband within an initializer could also work, but you may end up missing some boot up coverage. To start collection require Coverband as early as possible.
require 'coverband'
require File.dirname(__FILE__) + '/config/environment'
use Coverband::BackgroundMiddleware
run ActionController::Dispatcher.new
You can check it out locally by running the Coverband Demo App.
-
View overall coverage information
-
Drill into individual file coverage
-
View individual file details
-
Clear Coverage - disabled by default as it could be considered a dangerous operation in production. Enable with
config.web_enable_clear
or leave off and clear from the rake task.-
Clear coverage report
This will clear the coverage data. This wipes out all collected data.
-
Clear individual file coverage
This will clear the details of the file you are looking at. This is helpful if you don't want to lose all Coverage data but made a change that you expect would impact a particular file.
-
-
Force coverage collection
This triggers coverage collection on the current webserver process. Useful in development but confusing in production environments where many ruby processes are usually running.
The columns in the web UI are as follows:
- % covered - Percentage of total relevant lines covered
- % runtime - Percentage of the runtime lines covered where runtime lines are lines that are hit after the application has been eagerly loaded
- Lines - Total lines in the file including lines unreachable or uncover-able. An unreachable line would be an empty line with no code, comments, or
end
statements. - Relevant lines - Lines that are coverable, i.e. not empty
- Lines runtime - Total lines minus uncoverable lines minus the lines that are only hit during eager loading of application
- Lines missed - Relevant lines not covered
- Avg hits/line - Total of coverage to the file divided by relevant lines.
When viewing an individual file, a line of code such as a class or method definition may appear green because it is eager loaded by the application, but still not be hit at all in runtime by actual users.
Coverband comes with a mountable rack app for viewing reports. For Rails this can be done in config/routes.rb
with:
Rails.application.routes.draw do
mount Coverband::Reporters::Web.new, at: '/coverage'
end
But don't forget to protect your source code with proper authentication. Something like this when using devise:
Rails.application.routes.draw do
authenticate :user, lambda { |u| u.admin? } do
mount Coverband::Reporters::Web.new, at: '/coverage'
end
end
or you can enable basic auth by setting ENV['COVERBAND_PASSWORD']
or via your configuration config.password = <YOUR_COMPLEX_UNGUESSABLE_PASSWORD>
The coverage server can also be started standalone with a rake task:
bundle exec rake coverband:coverage_server
The web UI should then be available here: http:https://localhost:9022/
If you want to run on an alternative port:
COVERBAND_COVERAGE_PORT=8086 bundle exec rake coverband:coverage_server
This is especially useful for projects that are api only and cannot support the mounted rack app. To get production coverage, point Coverband at your production redis server and ensure to checkout the production version of your project code locally.
COVERBAND_REDIS_URL=redis:https://username:password@redis_production_server:2322 bundle exec rake coverband:coverage_server
Take Coverband for a spin on the live Heroku deployed Coverband Demo. The full source code for the demo is available to help with installation, configuration, and understanding of basic usage.
If you need to configure Coverband, this can be done by creating a config/coverband.rb
file relative to your project root.
- See lib/coverband/configuration.rb for all options
- By default Coverband will try to store data to Redis * Redis endpoint is looked for in this order:
ENV['COVERBAND_REDIS_URL']
,ENV['REDIS_URL']
, orlocalhost
Below is an example config file for a Rails 5 app:
# config/coverband.rb NOT in the initializers
Coverband.configure do |config|
config.store = Coverband::Adapters::RedisStore.new(Redis.new(url: ENV['MY_REDIS_URL']))
config.logger = Rails.logger
# config options false, true. (defaults to false)
# true and debug can give helpful and interesting code usage information
# and is safe to use if one is investigating issues in production, but it will slightly
# hit perf.
config.verbose = false
# default false. button at the top of the web interface which clears all data
config.web_enable_clear = true
# default false. Experimental support for routes usage tracking.
config.track_routes = true
end
Do you use figaro, mc-settings, dotenv or something else to inject environment variables into your app? If so ensure you have that done BEFORE Coverband is required.
For example if you use dotenv, you need to do this, see https://github.com/bkeepers/dotenv#note-on-load-order
gem 'dotenv-rails', require: 'dotenv/load'
gem 'coverband'
gem 'other-gem-that-requires-env-variables'
Sometimes you have files that are known to be valuable, perhaps in other environments or something that is just run very infrequently. Opposed to having to mentally filter them out of the report, you can just have them ignored in the Coverband reporting by using config.ignore
as shown below. Ignore takes a string but can also match with regex rules see how below ignores all rake tasks as an example.
config.ignore += ['config/application.rb',
'config/boot.rb',
'config/puma.rb',
'config/schedule.rb',
'bin/.*',
'config/environments/.*',
'lib/tasks/.*']
Ignoring Custom Gem Locations: Note, if you have your gems in a custom location under your app folder you likely want to add them to config.ignore
. For example, if you have your gems not in the default ignored location of app/vendor
but in app/gems
, you would need to add gems/*
to your ignore list.
Coverband allows an optional feature to track all view files that are used by an application.
This feature is enabled by default. To stop this feature, disable the feature in your Coverband config.
config.track_views = false
Coverband provides a view of all of its current settings. Sometimes you might want to hide this view, such as when sharing coverband data with a large number of developers of varying trust levels. You can disable the settings view like so:
config.hide_settings = false
If all your coverage is being counted as loading or eager_loading coverage, and nothing is showing as runtime Coverage the initialization hook failed for some reason. The most likely reason for this issue is manually calling eager_load!
on some Plugin/Gem. If you or a plugin is altering the Rails initialization process, you can manually flip Coverband to runtime coverage by calling these two lines, in an after_initialize
block, in application.rb
.
config.after_initialize do
unless Coverband.tasks_to_ignore?
Coverband.report_coverage # record the last of the loading coverage
Coverband.runtime_coverage! # set all future coverage to runtime
end
end
or if you know you are manually calling eager load anywhere in your initialization process immediately after call those two lines. A user reported an issue after calling ResqueWeb::Engine.eager_load!
for example.
Rails.application.routes.draw do
ResqueWeb::Engine.eager_load!
Coverband.report_coverage
Coverband.runtime_coverage!
end
If you have many servers and they all hit Redis at the same time you can see spikes in your Redis CPU, and memory. This is due to a concept called cache stampede.
It is better to spread out the reporting across your servers. A simple way to do this is to add a random wiggle on your background reporting. This configuration option allows a wiggle. The right amount of wiggle depends on the number of servers you have and how willing you are to have delays in your coverage reporting. I would recommend at least 1 second per server. Note, the default wiggle is set to 30 seconds.
Add a wiggle (in seconds) to the background thread to avoid all your servers reporting at the same time:
config.reporting_wiggle = 30
Another way to avoid cache stampede is to omit some reporting on starting servers. Coverband stores the results of eager_loading to Redis at server startup. The eager_loading results are the same for all servers, so there is no need to save all results. By configuring the eager_loading results of some servers to be stored in Redis, we can reduce the load on Redis during deployment.
# To omit reporting on starting servers, need to defer saving eager_loading data
config.defer_eager_loading_data = true
# Store eager_loading data on 5% of servers
config.send_deferred_eager_loading_data = rand(100) < 5
# Store eager_loading data on servers with the environment variable
config.send_deferred_eager_loading_data = ENV.fetch('ENABLE_EAGER_LOADING_COVERAGE', false)
Coverband on very high volume sites with many server processes reporting can have a race condition which can cause hit counts to be inaccurate. To resolve the race condition and reduce Ruby memory overhead we have introduced a new Redis storage option. This moves the some of the work from the Ruby processes to Redis. It is worth noting because of this, it has larger demands on the Redis server. So adjust your Redis instance accordingly. To help reduce the extra redis load you can also change the background reporting frequency.
- Use a dedicated Coverband redis instance:
config.store = Coverband::Adapters::HashRedisStore.new(Redis.new(url: redis_url))
- Adjust from default 30s reporting
config.background_reporting_sleep_seconds = 120
See more discussion here.
Please note that with the Redis Hash Store, everytime you load the full report, Coverband will execute HGETALL
queries in your Redis server twice for every file in the project (once for runtime coverage and once for eager loading coverage). This shouldn't have a big impact in small to medium projects, but can be quite a hassle if your project has a few thousand files.
To help reduce the extra redis load when getting the coverage report, you can enable get_coverage_cache
(but note that when doing that, you will always get a previous version of the report, while a cache is re-populated with a newer version).
- Use Hash Redis Store with get coverage cache:
config.store = Coverband::Adapters::HashRedisStore.new(redis, get_coverage_cache: true)
Now that Coverband uses MD5 hashes there should be no reason to manually clear coverage unless one is testing, changing versions, or possibly debugging Coverband itself.
rake coverband:clear
This can also be done through the web if config.web_enable_clear
is enabled.
Rails apps should automatically include the tasks via the Railtie.
For non Rails apps, either add the below to your Rakefile
or to a file included in your Rakefile
such as lib/tasks/coverband.rake
if you want to break it up that way.
require 'coverband'
Coverband.configure
require 'coverband/utils/tasks'
Verify it works
rake -T coverband
rake coverband:clear # reset coverband coverage data
rake coverband:coverage # report runtime coverband code coverage
Coverband starts on require of the the library which is usually done within the Gemfile. This can be disabled by setting the COVERBAND_DISABLE_AUTO_START
environment variable. This environment variable can be useful to toggle Coverband on and off in certain environments.
NOTE: That any value set for COVERBAND_DISABLE_AUTO_START
is considered true, it does not match the string content but only checks the presence of the ENV variable.
In order to start Coverband manually when this flag is enabled, call Coverband.configure
followed by Coverband.start
.
Coverband.configure
Coverband.start
Note: To debug issues getting Coverband working. I recommend running in development mode, by turning verbose logging on config.verbose = true
and passing in the Rails.logger config.logger = Rails.logger
to the Coverband config. We respect the log level, and I would recommend log level info generally, but if you are investigating a problem Coverband logs additional data at the debug
level. This makes it easy to follow in development mode. Be careful not to leave these on in production as they will affect performance.
If you are trying to debug locally wondering what code is being run during a request. The verbose modes config.verbose = true
&& Rails.logger.level = :debug
. With true set it will output the number of lines executed per file, to the passed in log.
If you start seeing SystemStackError: stack level too deep errors from background jobs after installing Coverband, this means there is another patch for ResqueWorker that conflicts with Coverband's patch in your application. To fix this, change Coverband gem line in your Gemfile to the following:
gem 'coverband', require: ['alternative_coverband_patch', 'coverband']
If you currently have require: false, remove the 'coverband' string from the require array above so the gem line becomes like this:
gem 'coverband', require: ['alternative_coverband_patch']
This conflict happens when a ruby method is patched twice, once using module prepend, and once using method aliasing. See this ruby issue for details. The fix is to apply all patches the same way. By default, Coverband will apply its patch using prepend, but you can change that to method aliasing by adding require: ['alternative_coverband_patch'] to the gem line as shown above.
A few folks have asked about what size of Redis is needed to run Coverband. I have some of our largest services with hundreds of servers on cache.m3.medium with plenty of room to spare. I run most apps on the smallest AWS Redis instances available and bump up only if needed or if I am forced to be on a shared Redis instance, which I try to avoid. On Heroku, I have used it with most of the 3rd party and also been fine on the smallest Redis instances, if you have hundreds of dynos you would likely need to scale up. Also note there is a tradeoff one can make, Coverband::Adapters::HashRedisStore
will use LUA on Redis and increase the Redis load, while being nicer to your app servers and avoid potential lost data during race conditions. While the Coverband::Adapters::RedisStore
uses in app memory and merging and has lower load on Redis.
Rake task that outputs dead methods based on current coverage data:
bundle exec rake coverband:dead_methods
Outputs:
---------------------------------------------------------------------------------------------------
| file | class | method | line_number |
| ./config/routes.rb | AdminConstraint | matches? | 20 |
| ./app/controllers/home_controller.rb | HomeController | trigger_jobs | 8 |
| ./app/controllers/home_controller.rb | HomeController | data_tracer | 14 |
| ./app/controllers/posts_controller.rb | PostsController | edit | 22 |
| ./app/controllers/posts_controller.rb | PostsController | destroy_bad_dangerously | 73 |
---------------------------------------------------------------------------------------------------
- Coverband 3.0.X+ requires Ruby 2.3+
- Coverband currently requires Redis for production usage
We will match Heroku & Ruby's support lifetime, supporting the last 3 major Ruby releases. For details see supported runtimes.
For Rails, we will follow the policy of the Rails team maintenance policy. We officially support the last two major release versions, while providing minimal support (major bugs / security fixes) for an additional version. This means at the moment we primarily target Rails 6.x, 5.x, and will try to keep current functionality working for Rails 4.x but may release new features that do not work on that target.
Coverband is compatible with JRuby. If you want to run on JRuby note that I haven't benchmarked and I believe the perf impact on older versions of JRuby could be significant. Improved Coverage support is in JRuby master, and will be in the next release.
- older versions of JRuby need tracing enabled to work (and this could cause bad performance)
- run Jruby with the
--debug
option - add into your
.jrubyrc
thedebug.fullTrace=true
setting
- run Jruby with the
- For best performance the
oneshot_lines
is recommended, and in the latest releases should have very low overhead - See JRuby support in a Rails app configured to run via JRuby, in Coverband Demo
- JRuby is tested via CI against Rails 5 and 6
If you are working on adding features, PRs, or bugfixes to Coverband this section should help get you going.
- Fork it
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature'
) - Push to the branch (
git push origin my-new-feature
) - Make sure all tests are passing (run
bundle install
, make sure Redis is running, and then executerake test
) - Create new Pull Request
If you submit a change please make sure the tests and benchmarks are passing.
- run tests:
bundle exec rake
BUNDLE_GEMFILE=Gemfile.rails7 bundle exec rake
(Same tests using rails 7 instead of 6)
- view test coverage:
open coverage/index.html
- run the benchmarks before and after your change to see impact
rake benchmarks
- run a single test by line number like rspec:
bundle exec m test/coverband/reporters/html_test.rb:29
- run a single test file:
bundle exec ruby test/coverband/collectors/translation_tracker_test.rb
- total fail on front end code, for line for line coverage, because of the precompiled template step basically coverage doesn't work well for
erb
,slim
, and the like.- related it will try to report something, but the line numbers reported for
ERB
files are often off and aren't considered useful. I recommend filtering out .erb using theconfig.ignore
option. The default configuration excludes these files - NOTE: We now have file level coverage for view files, but don't support line level detail
- related it will try to report something, but the line numbers reported for
- Coverage does NOT work when used alongside Scout APM Auto Instrumentation
- In an environment that uses Scout's
AUTO_INSTRUMENT=true
(usually production or staging) it stops reporting any coverage, it will show one or two files that have been loaded at the start but everything else will show up as having 0% coverage - Bug tracked here: scoutapp/scout_apm_ruby#343
- In an environment that uses Scout's
- Coverband, Elastic APM and resque
- In an environment that uses the Elastic APM ruby agent, resque jobs will fail with
Transactions may not be nested. Already inside #<ElasticAPM::Transaction>
if theelastic-apm
gem is loaded before thecoverband
gem - Put
coverage
ahead ofelastic-apm
in your Gemfile
- In an environment that uses the Elastic APM ruby agent, resque jobs will fail with
- Bootsnap, The methods used by bootsnap do not support having coverage enabled, so you can either have Coverband or bootsnap, but not both.
What files have been synced to Redis?
Coverband.configuration.store.covered_files
What is the coverage data in Redis?
Coverband.configuration.store.coverage
A diagram of the code.
The Coverband logo was created by Dave Woodall. Thanks Dave!
This is a MIT License project... See the file LICENSE for copying permission.