coverband 2.0.0 → 2.0.3

checksums.yaml

@@ -1,7 +1,7 @@
 ---
-SHA256:
-  metadata.gz: 104227eaef7c235ff16b13a0f80c5f29fe4117deac05acbed7553e3343be7ea9
-  data.tar.gz: dd5a621f881e955c52c1a2acf903f3bc5abd550bc015650851cb385ff76bf758
+SHA1:
+  metadata.gz: 8d6a0e6c24d29f4b432cd6a514b5c1bbca2e699d
+  data.tar.gz: d2ef15b6d6b100396b265068acdf1d4d83394823
 SHA512:
-  metadata.gz: 7a2c2041a887b5ac729a540489b20e48fba117e2d70e827f3b7c5fb6da21382fa6786a093e915232771abc7a0903f78b3484713e39394fdf3bbf6cda6f8f57c9
-  data.tar.gz: 38ed9c82a8a607d349f4edef901d7d348b128c9ff2f6ad6276df388f29ee25e98c6e9534f3e0d4d16d1902f958575f72aa6676c8499d81f6a44b72eaaef534fc
+  metadata.gz: fd0b35c4a1abceebcda0791290dc71e0fc382c4980c87d09639371a2d4f048b0d79b3938b18c3facbe5e78fcf25c2f1aa8d3766eaca761dd590ecc71138410d9
+  data.tar.gz: d0104388613abebf8575d4701b8cda4ff0caaaa5f14d57c72535c7cf68d178f432ac584a7f9c700e625b724c542b78827d5964ab24573e81562bf0b5688e8dd0

data/.gitignore

@@ -18,4 +18,5 @@ spec/reports
 test/tmp
 test/version_tmp
 tmp
-.byebug_history
+.byebug_history
+.env

data/README.md

@@ -4,11 +4,13 @@ Build Status: [![Build Status](https://travis-ci.org/danmayer/coverband.svg?bran
 
 <p align="center">
   <a href="#key-features">Key Features</a> •
+  <a href="#coverband-demo">Coverband Demo</a> •
   <a href="#how-to-use">How To Use</a> •
   <a href="#installation">Installation</a> •
   <a href="#configuration">Configuration</a> •
   <a href="#usage">Usage</a> •
-  <a href="#license">License</a>
+  <a href="#license">License</a> •
+  <a href="/changes.md">Change Log / Roadmap</a>
 </p>
 
 A gem to measure production code usage, showing each line of code that is executed. Coverband allows easy configuration to collect and report on production code usage. It can be used as Rack middleware, wrapping a block with sampling, or manually configured to meet any need (like usage during background jobs).
@@ -17,24 +19,31 @@ Note: Coverband is not intended for test code coverage, for that just check out
 
 ## Key Features
 
-* Allows sampling to avoid the performance overhead on every request.
+The primary goal of Coverband is giving deep insight into your production runtime usage of your application code, while having the least impact on performance possible.
+
+* Low performance overhead
+* Various controls from sampling, data collection rate, etc to further control performance
 * Ignore directories to avoid overhead data collection on vendor, lib, etc.
-* Take a baseline to get initial app execution during app initialization. (the baseline is important because some code is executed during app load, but might not be invoked during any requests, think prefetching, initial cache builds, setting constants, etc...)
-* Development mode for additional code usage details (number of LOC execution during single request, etc).
+* Development mode, offers deep insight of code usage details (number of LOC execution during single request, etc) during development.
+* Easy setup for any Ruby Rack based web framework (Rails, Sinatra, etc)
+* Allows for integration with any other Ruby application flows (background jobs, crons, scripts)
+
+## Coverband Demo
+
+Take Coverband for a spin on the live Heroku deployed [Coverband Demo](https://coverband-demo.herokuapp.com/). The [full source code for the demo](https://github.com/danmayer/coverband_demo) is available to help with configuration and understanding of basic usage.
 
 # How To Use
 
 Below is my Coverband workflow, which hopefully will help other best use this library.
 
-* install coverband.
-* take baseline measurment: `rake coverband:baseline` (__note: never run baseline on production__)
-* validate baseline with  `rake coverband:coverage`
+* install coverband
+* start your app and hit a few endpoints
+* validate data collection and code coverage with  `rake coverband:coverage`
 * test setup in development (hit endpoints and generate new report)
 * deploy to staging and verify functionality
 * deploy to production and verify functionality
-* every 2 weeks or with major releases
+* every 2 weeks or so, with major releases
    * clear old coverage: `rake coverband:clear`
-   * take new baseline: `rake coverband:baseline`
    * deploy and verify coverage is matching expectations
 * __COVERAGE DRIFT__
    * if you never clear you have lines of code drift from when they were recorded
@@ -57,7 +66,7 @@ Details on a example Sinatra app
 
 Follow the below section to install and configure Coverband.
 
-![coverband installation](https://raw.githubusercontent.com/danmayer/coverband/feature/via_coverage/docs/coverband_install.gif?raw=true)
+![coverband installation](https://raw.githubusercontent.com/danmayer/coverband/master/docs/coverband-install-resize.gif)
 
 ## Prerequisites
 
@@ -102,6 +111,10 @@ Coverband.configure do |config|
   config.root              = Dir.pwd
   config.collector         = 'coverage'
   config.redis             = Redis.new(url: ENV['REDIS_URL']) if defined? Redis
+  # TODO NOTE THIS IS A ISSUE IN THE 2.0 release you set something like redis and the store
+  # I need to look a bit more at this but got one bug report quickly after release
+  # (even though test builds didnt need)
+  config.store             = Redis.new(url: ENV['REDIS_URL']) if defined? Redis
   config.ignore            = %w[vendor .erb$ .slim$]
   # add paths that you deploy to that might be different than your local dev root path
   config.root_paths        = []
@@ -134,8 +147,7 @@ require 'coverband/tasks'
 This should give you access to a number of Coverband tasks
 
 ```bash
-bundle exec rake -T coverband
-rake coverband:baseline      # record coverband coverage baseline
+rake -T coverband
 rake coverband:clear         # reset coverband coverage data
 rake coverband:coverage      # report runtime coverband code coverage
 ```
@@ -190,10 +202,10 @@ run ActionController::Dispatcher.new
 
 # Verify Correct Installation
 
-* Gather baseline metrics: run `bundle exec rake coverband:baseline` (__note: never run baseline on production__)
-* run `bundle exec rake coverband:coverage` this will show app initialization coverage
+* boot up your application
+* run `rake coverband:coverage` this will show app initialization coverage
 * run app and hit a controller (hit at least +1 time over your `config.startup_delay` setting default is 0)
-* run `bundle exec rake coverband:coverage` and you should see coverage increasing for the endpoints you hit.
+* run `rake coverband:coverage` and you should see coverage increasing for the endpoints you hit.
 
 ## Installation Script
 
@@ -212,10 +224,11 @@ bundle install
 
 # create config/coverband.rb
 # copy the config from the readme
-# If you don't set REDIS_URL, remove that to use default localhose
+# If you don't set REDIS_URL, remove that to use default localhost
 
+# Make some code so we can look at the coverage
 rails generate scaffold blogs
-bundle exec rake db:migrate
+rake db:migrate
 
 # open Rakefile, add lines
 require 'coverband'
@@ -228,10 +241,9 @@ rake -T coverband
 # configure config/application.rb
 # copy lines from readme
 
-
-rake coverband:baseline
+# start up your app
 rake coverband:coverage
-# view baseline coverage
+# view boot up coverage
 
 rails s
 
@@ -251,41 +263,11 @@ rake coverband:coverage
 - [Sinatra app](https://github.com/danmayer/churn-site)
 - [Non Rack Ruby app](https://github.com/danmayer/coverband_examples)
 
-### Coverband Baseline
-
-__TLDR:__ Baseline is app initialization coverage, not captured during runtime.
-
-Before starting a service verify your baseline by running `rake coverband:baseline` followed by `rake coverband:coverage` to view what your baseline coverage looks like before any runtime traffic has been recorded.
-
-The baseline seems to cause some confusion. Basically, when Coverband records code usage, it will not request initial startup code like method definition, it covers what it hit during run time. This would produce a fairly odd view of code usage. To cover things like defining routes, dynamic methods, and the like Coverband records a baseline. The baseline should capture coverage of app initialization and boot up, we don't want to do this on deploy as it can be slow. So we take a recording of boot up as a one time baseline Rake task `bundle exec rake coverband:baseline`.
-
-1. Start your server with `rails s` or `rackup config.ru`.
-2. Hit your development server exercising the endpoints you want to verify Coverband is recording (you should see debug outputs in your server console)
-3. Run `rake coverband:coverage` again, previously it should have only shown the baseline data of your app initializing. After using it in development it should show increased coverage from the actions you have exercised.
-
-Note: if you use `rails s` and data isn't recorded, make sure it is using your `config.ru`.
-
-### Baseline Missing data
-
-The default Coverband baseline task will try to detect your app as either Rack or Rails environment. It will load the app to take a baseline reading. The baseline coverage is important because some code is executed during app load, but might not be invoked during any requests, think prefetching, initial cache builds, setting constants, etc. If the baseline task doesn't load your app well you can override the default baseline to create a better baseline yourself. Below for example is how I take a baseline on a pretty simple Sinatra app.
-
-```ruby
-namespace :coverband do
-  desc "get coverage baseline"
-  task :baseline_app do
-    Coverband::Reporter.baseline {
-      require 'sinatra'
-      require './app.rb'
-    }
-  end
-end
-```
-
 ### View Coverage
 
-You can view the report different ways, but the easiest is the Rake task which opens the Simplecov formated HTML.
+You can view the report different ways, but the easiest is the Rake task which opens the SimpleCov formatted HTML.
 
-`bundle exec rake coverband:coverage`
+`rake coverband:coverage`
 
 This should auto-open in your browser, but if it doesn't the output file should be in `coverage/index.html`
 
@@ -313,7 +295,7 @@ Coverband::Reporter.clear_coverage(Redis.new(:host => 'target.com', :port => 678
 ```
 You can also do this with the included rake tasks.
 
-### Manual configuration (for example for background jobs)
+### Manual Configuration (for example for background jobs)
 
 It is easy to use Coverband outside of a Rack environment. Make sure you configure Coverband in whatever environment you are using (such as `config/initializers/*.rb`). Then you can hook into before and after events to add coverage around background jobs, or for any non Rack code.
 
@@ -360,6 +342,83 @@ coverband.sample {
 }
 ```
 
+### Manual Configuration (for cron jobs / Raketasks)
+
+A question about [supporting cron jobs and Rake tasks](https://github.com/danmayer/coverband/issues/106) was asked by [@ndbroadbent](https://github.com/ndbroadbent), there are a couple ways to go about it including his good suggestion.
+
+He extended the Coverband Rake tasks by adding `lib/tasks/coverband.rake` with support to wrap all Rake tasks with coverband support.
+
+```
+require 'coverband'
+Coverband.configure
+require 'coverband/tasks'
+
+# Wrap all Rake tasks with Coverband
+current_tasks = Rake.application.top_level_tasks
+if current_tasks.any? && current_tasks.none? { |t| t.to_s.match?(/^coverband:/) }
+  current_tasks.unshift 'coverband:start'
+  current_tasks.push 'coverband:stop_and_save'
+end
+
+namespace :coverband do
+  task :start do
+    Coverband::Base.instance.start
+  end
+
+  task :stop_and_save do
+    Coverband::Base.instance.stop
+    Coverband::Base.instance.save
+  end
+end
+```
+
+That is a interesting approach and if you Run all your cron jobs as Rake tasks might work well for you. In a production application where we run Coverband, we run all of our Cron jobs with the `rails runner` script. We took this alternative approach which will wrap all runner jobs with Coverband recording, by creating `lib/railties/coverage_runner.rb`.
+
+```
+require 'rails'
+
+# Capture code coverage during our cron jobs
+class CoverageRunner < ::Rails::Railtie
+  runner do
+    Coverband::Collectors::Base.instance.start
+    at_exit do
+      Coverband::Collectors::Base.instance.report_coverage
+    end
+  end
+end
+```
+
+### safe_reload_files: Forcing Coverband to Track Coverage on Files loaded during boot
+
+The way Coverband is built it will record and report code usage in production for anything `required` or `loaded` after calling `Coverband.start`. This means some of Rails initial files and Gems are loaded before you can generally call `Coverband.start` for example if you use the `application.rb` to initialize and start Coverband, that file will be reported as having no coverage, as it can't possibly start Coverband before the file is loaded. 
+
+The `safe_reload_files` reload option in the configuration options can help to ensure you can track any files you want regardless of them loading before Coverband. For example if I wanted to show the coverage of `config/coverband.rb` which has to be loaded before calling `Coverband.start` I could do that by adding that path to the `safe_reload_files` option.
+
+```
+Coverband.configure do |config|
+  # ... a bunch of other options
+  # using the new safe reload to enforce files loaded
+  config.safe_reload_files = ['config/coverband.rb']
+end
+```
+By adding any files above you will get reporting on those files as part of your coverage runtime report.
+
+
+### Collecting Gem / Library Usage
+
+By default Coverband has assumed you are trying to track your application code usage not all the supporting framework and library (Gems) code usage. There has been some good points and reasons folks want to track library usage, for example to find out which Gems they aren't actually using in production. See some of the discussion on [issue 21](https://github.com/danmayer/coverband/issues/21).
+
+* Using the Tracepoint Collector
+   * just make sure to set `Coverband.configuration.include_gems = true` in your config options
+   * note by tracking all the additional usage this can have significant performance impacts of the Tracepoint implementation
+* Using the Coverage Collector
+   * use the `safe_reload_files` feature to add the path of all gem files you wish to track
+   * --- or ---
+   * ensure you call `Coverband.start` before loading all your gems
+      * while possible this is currently hard as Rails and most environments load your whole Gemfile
+      * looking for an improve and easier way to support this.  
+
+
 ### Verbose Debug / Development Mode
 
 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. This makes it easy to follow in development mode. Be careful to not leave these on in production as they will affect performance.
@@ -400,6 +459,83 @@ Coverband::Reporter.report :additional_scov_data => [data]
 
 You can also pass a `:additional_scov_data => [data]` option to `Coverband::Reporter.get_current_scov_data` to write out merged data.
 
+### Writing Coverband Results to S3
+
+If you add some additional Coverband configuration your coverage html report will be written directly to S3, update `config/coverband.rb` like below.
+
+```
+  # configure S3 integration
+  config.s3_bucket = 'coverband-demo'
+  config.s3_region = 'us-east-1'
+  config.s3_access_key_id = ENV['AWS_ACCESS_KEY_ID']
+  config.s3_secret_access_key = ENV['AWS_SECRET_ACCESS_KEY']
+```
+
+### Viewing / Hosting S3 Coverband results in app
+
+Beyond writing to S3 you can host the S3 file with a build in Sintatra app in Coverband. Just configure your Rails route `config/routes.rb`
+
+```
+Rails.application.routes.draw do
+  # ... lots of routes
+  mount Coverband::Reporters::Web.new, at: '/coverage'
+end
+```
+
+__NOTE__: ADD PASSWORD PROTECTION OR YOU CAN EXPOSE ALL YOUR SOURCE CODE
+
+It is easy to add some basic protect around the coverage data, below shows how you can use devise or basic auth, by adding a bit of code to your `config/routes.rb` file.
+
+```
+# protect with existing Rails devise configuration
+devise_constraint = lambda do |request|
+  request.env['warden'] && request.env['warden'].authenticate? && request.env['warden'].user.admin?
+end
+
+# protect with http basic auth
+# curl --user foo:bar http://localhost:3000/coverage
+basic_constraint = lambda do |request|
+  return true if Rails.env.development?
+  if ActionController::HttpAuthentication::Basic.has_basic_credentials?(request)
+    credentials = ActionController::HttpAuthentication::Basic.decode_credentials(request)
+    email, password = credentials.split(':')
+
+    email == 'foo' && password = 'bar'
+  end
+end
+
+Rails.application.routes.draw do
+  # ... lots of routes
+  constraints basic_constraint do
+    mount Coverband::Reporters::Web.new, at: '/coverage'
+  end
+end
+```
+
+### Conflicting .Simplecov: Issue with Missing or 0% Coverage Report
+
+If you use SimpleCov to generate code coverage for your tests. You might have setup a `.simplecov` file to help control and focus it's output. Often the settings you want for your test's code coverage report are different than what you want Coverband to be reporting on. Since Coverband uses the SimpleCov HTML formatter to prepare it's report.
+
+So if you had something like this in a `.simplecov` file in the root of your project, as reported in [issue 83](https://github.com/danmayer/coverband/issues/83)
+
+```
+require 'simplecov'
+
+SimpleCov.start do
+  add_filter 'app/admin'
+  add_filter '/spec/'
+  add_filter '/config/'
+  add_filter '/vendor/'
+  add_filter 'userevents'
+end
+```
+
+You could see some confusing results... To avoid this issue Coverband has a Rake task that will ignore all Simplecov filters.
+
+`rake coverband:coverage_no_filters`
+
+This will build the report after disabling any `.simplecov` applied settings.
+
 # Contributing To Coverband
 
 If you are working on adding features, PRs, or bugfixes to Coverband this section should help get you going.
@@ -408,24 +544,24 @@ If you are working on adding features, PRs, or bugfixes to Coverband this sectio
 2. Create your feature branch (`git checkout -b my-new-feature`)
 3. Commit your changes (`git commit -am 'Add some feature'`)
 4. Push to the branch (`git push origin my-new-feature`)
-5. Make sure all tests are passing (run `bundle install`, make sure Redis is running, and then execute `bundle exec rake test`)
+5. Make sure all tests are passing (run `bundle install`, make sure Redis is running, and then execute `rake test`)
 6. Create new Pull Request
 
 ### Tests & Benchmarks
 
 If you submit a change please make sure the tests and benchmarks are passing.
 
-* run tests: `bundle exec rake`
+* run tests: `rake`
 * view test coverage: `open coverage/index.html`
 * run the benchmarks before and after your change to see impact
-   * `bundle exec rake benchmarks` 
+   * `rake benchmarks` 
 
 ### Known Issues
 
 * __total fail__ on front end code, 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 the `config.ignore` option. 
 * If you have SimpleCov filters, you need to clear them prior to generating your coverage report. As the filters will be applied to Coverband as well and can often filter out everything we are recording.
-* the line numbers reported for `ERB` files are often off and aren't considered useful. I recommend filtering out .erb using the `config.ignore` option.
-* coverage doesn't show for Rails `config/application.rb` or `config/boot.rb` as they get loaded when loading the Rake environment prior to starting to record the baseline..
+* coverage doesn't show for Rails `config/application.rb` or `config/boot.rb` as they get loaded when loading the Rake environment prior to starting the `Coverage` library.
 
 ### Debugging Redis Store
 
@@ -496,19 +632,19 @@ Similar format to redis store, but array with integer values
 
 ### Todo
 
+* add articles / podcasts like prontos readme https://github.com/prontolabs/pronto
 * graphite adapters (it would allow passing in date ranges on usage)
 * perf test for array vs hash
 * redis pipeline around hash (or batch get then push)
-* pass in namespace to redis (coverage vs baseline)
-* what about having baseline a onetime recording into redis no merge later
 * move to SimpleCov console out, or make similar console tabular output
-* Fix network performance by logging to files that purge later (like NR) (far more time lost in TracePoint than sending files, hence not a high priority, but would be cool)
+* Improve network performance by logging to files that purge later (like NR) (far more time lost in TracePoint than sending files, hence not a high priority, but would be cool)
 * Add support for [zadd](http://redis.io/topics/data-types-intro) so one could determine single call versus multiple calls on a line, letting us determine the most executed code in production.
 * Possibly add ability to record code run for a given route
+* integrate recording with deploy tag or deploy timestamp
+   *  diff code usage across deployed versions 
 * Improve client code api, around manual usage of sampling (like event usage)
 * ability to change the Coverband config at runtime by changing the config pushed to the Redis hash. In memory cache around the changes to only make that call periodically.
 * Opposed to just showing code usage on a route allow 'tagging' events which would record line coverage for that tag (this would allow tagging all code that modified an ActiveRecord model for example
-* mountable rack app to view coverage similar to flipper-ui
 * support runner, active job, etc without needed extra config (improved railtie integration)
 
 # Resources

data/Rakefile

@@ -19,3 +19,10 @@ desc 'load irb with this gem'
 task :console do
   exec 'irb -I lib -r coverband'
 end
+
+# This is really just for testing and development because without configuration
+# Coverband can't do much
+desc 'start webserver'
+task :server do
+  exec 'rackup -I lib'
+end

data/changes.md

@@ -12,9 +12,49 @@ Will be the fully modern release that drops maintenance legacy support in favor
    * add built-in support for easy loading via Railties
    * expects to add safe list support to force reload files one wants coverage on that may happen outside of the standard load order
    * built in support for activejob, sidekiq, and other common frameworks
+* code route tracing (entry point to all code executed for example /some_path -> code coverage of that path)
+
+# Alpha
+
+### 3.0.0
+
+* drop Tracepoint
+* background thread reporter
+
+# 2.0.3
+
+* don''t include docs in the gemfile thanks @bquorning
+* pipeline_redis to reduce network overhead thanks @Kallin
+* various additional benchmarks @danmayer
+* Filter out files with no coverage thanks  @kbaum
+
 
 # Released
 
+### 2.0.2
+
+* fix possible nil error on files that changed since initial recording @viktor-silakov
+* add improve error logging in verbose mode (stacktrace) @viktor-silakov
+* improved logging level support @viktor-silakov
+* launch Coverband demo and integrate into Readme / Documentation
+* fix on baseline to show an issue by @viktor-silakov
+* remove all coverband:baseline related features and documentation
+* dropped Sinatra requirement for web mountable page
+* fix on filestore by @danrabinowitz
+* fixes to the MemoryCacheStore by @kbaum
+
+### 2.0.1
+
+* add support for fine grained S3 configuration via Coverband config, thanks @a0s
+  * https://github.com/danmayer/coverband/pull/98
+* Using the file argument to self.configure in lib/coverband.rb, thanks @ThomasOwens
+  * https://github.com/danmayer/coverband/pull/100
+* added redis improvements allowing namespace and TTL thx @oded-zahavi
+* fix warnings about duplicate method definition
+* Add support for safe_reload_files based on full file path
+* Add support for Sinatra admin control endpoints
+* improved documentation
+
 ### 2.0.0
 
 Major release with various backwards compatibility breaking changes (generally related to the configuration). The 2.0 lifecycle will act as a mostly easy upgrade that supports past users looking to move to the much faster new Coverage Adapter.

data/config.ru

@@ -0,0 +1,4 @@
+# frozen_string_literal: true
+
+require ::File.expand_path('../lib/coverband', __FILE__)
+run Coverband::Reporters::Web.new

data/coverband.gemspec

@@ -14,7 +14,7 @@ Gem::Specification.new do |spec|
   spec.homepage      = 'https://github.com/danmayer/coverband'
   spec.license       = 'MIT'
 
-  spec.files         = `git ls-files`.split("\n")
+  spec.files         = `git ls-files`.split("\n").reject { |f| f.start_with?('docs') }
   spec.executables   = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
   spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
   spec.require_paths = ['lib']
@@ -26,7 +26,6 @@ Gem::Specification.new do |spec|
   spec.add_development_dependency 'rack'
   spec.add_development_dependency 'rack-test'
   spec.add_development_dependency 'rake'
-  spec.add_development_dependency 'sinatra'
   spec.add_development_dependency 'test-unit'
   spec.add_development_dependency 'redis'
   spec.add_development_dependency 'benchmark-ips'

data/lib/coverband/adapters/memory_cache_store.rb

@@ -9,16 +9,18 @@ module Coverband
     class MemoryCacheStore < Base
       attr_accessor :store
 
+      @@files_cache = {}
+
       def initialize(store)
         @store = store
       end
 
-      def self.reset!
-        files_cache.clear
+      def self.clear!
+        @@files_cache.clear
       end
 
       def clear!
-        self.class.reset!
+        self.class.clear!
       end
 
       def save_report(files)
@@ -26,28 +28,26 @@ module Coverband
         store.save_report(filtered_files) if filtered_files.any?
       end
 
-      # rubocop:disable Lint/IneffectiveAccessModifier
       private
 
-      def self.files_cache
-        @files_cache ||= {}
-      end
-
       def files_cache
-        self.class.files_cache
+        @@files_cache
       end
 
       def filter(files)
-        files.each_with_object({}) do |(file, lines), filtered_file_hash|
-          # first time we see a file, we pre-init the in memory cache to whatever is in store(redis)
-          line_cache = files_cache[file] ||= Set.new(store.covered_lines_for_file(file))
-          lines.reject! do |line|
-            line_cache.include?(line) ? true : (line_cache << line && false)
+        files.each_with_object({}) do |(file, covered_lines), filtered_file_hash|
+          if covered_lines != cached_file(file)
+            files_cache[file] = covered_lines
+            filtered_file_hash[file] = covered_lines
           end
-          filtered_file_hash[file] = lines if lines.any?
         end
       end
-      # rubocop:enable Lint/IneffectiveAccessModifier
+
+      def cached_file(file)
+        files_cache[file]  ||= store.covered_lines_for_file(file).each_with_object({}) do |(line_number, value), hash|
+          hash[line_number.to_i] = value.to_i
+        end
+      end
     end
   end
 end