It’s a sunny May afternoon and my bicycle is packed and ready for a breathtaking weekend on some of the most stunning roads of Austria.

The journey to Großglockner Hochalpenstraße was my first bikepacking experience and oh how excited I was counting days to the afternoon marking the start of the three day trip. The plan was to get close to Glocknerstraße from Salzburg on day one and then cycle over the alpine road towards Lienz on day two, while exploring the nearby viewpoints. Day three was about closing the loop back to Salzburg over the Felbertauern tunnel pass. Three days, three regions: Salzburg, Carinthia and East Tyrol.

Riding on my own, I expected lots of space to think about nothing while just absorbing the surroundings and pushing the bike forward on the numerous climbs. Pure enjoyment of the moment and a reset of the mind.

The first Friday stage was meant to be means to an end: arrive at the Glocknerstraße after a full day at the desk. I had some first thoughts about this article already in my head as I zoomed through city traffic. Funny enough, anxiety and anticipation for what’s coming was still occupying my headspace. I thought about the numbers, steep grades, elevation gains and potential risks. Do I have enough spare tubes? Will it be 400 or 380 km in total? Will I get caught in the rain?

Hochkönig

As soon as I reached the town of Bischofshofen and took the right turn into a steep road towards Dienter Sattel, my mindset drifted away from the earlier performance-focused attitude into a peaceful state of flow. So much more than means to an end. The traffic calmed down and there I was: me and the beast, the winding road facing the Salzburger giant, the Hochkönig. Cool air from road-adjacent waterfalls, mellow turns revealing more and more of the breathtaking landscape and just pushing the pedals hard was all I had in mind.

I won’t be bothering you with numbers and stats too much, though I’ll share the route in more detail in the appendix (1). Long story short, the final bit of the 17km Dienter Sattel ascent really squeezed my legs. The Dolomite-like views and a few sweet and loud 911s passing by were only the prelude to what was about to come on Day 2.

The descent of the day brought me to Maria Alm am Steinernen Meer with a big smile. The bags attached to my bike didn’t affect the handling and I was positively surprised with how they felt on the long downhill: bike was still fast, planted and sharp around the corners. The ski village welcomed me with a solid glass of Hefeweizen at an outdoor restaurant, surrounded by tourists and hikers resting quietly after their day adventures. Not finishing my ride back at the start felt amazing, no matter how trivial this sounds.

Maria Alm is also where one of my earlier anxieties materialised… I learned how the only USB-C cable I packed doesn’t charge my bike computer properly and that GPS routes no longer load on the Wahoo computer, due to a software problem. Well, I knew I’ll figure it somehow, and I did! I went for a short walk and then straight to bed, excited for the upcoming adventures.

Großglockner

If you decide to do this trip and sleep at hotels like I did, book them with breakfast. Austrian breakfast buffet game is strong, trust me.

Saturday started with soft-boiled eggs, fragrant bread rolls and a big pot of filter coffee. Such a nice surprise at the cheapest hotel I could find in Maria Alm.

The famous toll road across the High Tauern and nearby the Großglockner peak is an Austrian version of the Stelvio. Expect tourists, cars and motorbikes. Fortunately, starting early paid off and I had the climb to myself most of the day.

Departing from Maria Alm, it took a while to cycle along the Zell lake to Bruck, where the Großglocker climb officially begins. If you’re planning to just ride up there, Bruck is a perfect place to park the car. I was over the moon as the road elevated past the tree line to the first patches of snow, as end of May turned out to be perfect timing for epic snow walls. I did my best to capture all of it, but trust me the scale hits different when you’re there.

I love cycling up the Hochalpenstraße as an opportunity to observe how the landscape changes with every few hundred vertical meters gained. Few KMs past the toll road booths in Fusch and the forest eventually gives space to mountain pines, barren rocks, and then just snow that kept melting slowly in the sun rays on that day. The air got chilly. The breathtaking views really opened up. There was a moment where I could see far ahead into the valley, where the climb begun. I have no idea how far it was, but the distance was spectacular. Finally, a dozen or so switchbacks until the end I could see Fuscher Törl with the iconic 180-degree final turn and viewpoint, marking the end of a 2h+ climbing effort.

Though, I ended the journey a bit further at the cobbled “bonus climb” leading to a nearby peak, the Edelweißspitze. Had a moment of rest there and ate lunch on the sun terrace. The sun and leftover heat from the climb kept me warm only for a short moment, so I slowly started putting on more and more winter gear for the first descent of the day. All that while appreciating the accomplishment, the views and the Germknödel swimming in a bowl of vanilla sauce.

The well-deserved, long and twisty descent from Franz-Jozef’s Höhe towards Lienz in Osttirol quickly turned into the lowest point of the day and the whole trip. On the first few KMs as the road enters a wide parking area, I was stopped by police together with several cars and witnessed a cyclist being rescued by a medical helicopter after a severe accident with a car. I learned later the driver was on the incorrect lane (2).

As I’m writing this today, I know that the 44-year old cyclist from Salzburg passed away days after the crash due to irrecoverable trauma. My thoughts are with them and their relatives.

Day 3: Felbertauernstraße

It’s a Sunday morning. Bartek sends me this drum and bass set by Wilkinson, which was about to power me up the lengthy climb to Felbertauern tunnel.

https://soundcloud.com/sheetal-sethi/sleepless-nights

Sleepless Nights: Wilkinson (DJ Mix) by Wilkinson

Located west of and parallel to the Großglockner road, the pass is a popular Alpine crossing with heavy traffic. It’s a long fake-flat climb and honestly it felt like a grind, so music helped a lot. Was it worth it? Yes, would do this loop again, because loops are the best.

In the town of Matrei close to the tunnel entry, I called the toll booths and organised a minibus transfer. It’s not cheap (€30 per car) and unavoidable, as the 7km tunnel is not open for cyclists. The friendly Austrian tunnel operator who took me & the bike through to the other side provided good company and some laughs.

On the other side waited the final stretch, almost all the way downhill to my hometown Salzburg. Almost, because for whatever reason I decided to do the “bonus climb” to Hirschbichl. If you decide to follow the suggested route, get ready for up to 31% grades. Lowest gear, full power off the saddle and barely moving. Type-2 fun at times. Did I discover the steepest tarmac road in the area? Maybe!

The reward was there: a peaceful descent into Klausbachtal, Hintersee and further towards Salzburg, with great views (not worse than the rest of this trip) and no traffic, only tour buses allowed on the top section of the road. I stopped at the Klausbach valley for a final snack, a drink straight from the mountain stream and a moment of appreciation for what was about to end, as I was getting closer to home and the transition back to the day-to-day. I felt joy and gratitude for this cycling adventure around my still relatively new home region.

I hope you’re motivated to get up and do your own crazy thing, whatever it is. That was at least my goal for writing down all of these feelings and facts after the big weekend in the Alps. Ride On!✌️

Thanks to all supporters of my cycling journey: Early Birds Salzburg for keeping me in shape and able to do such adventures. Cyclite.cc for the saddle and frame bags. Marco Protič (probably the best mechanic in Salzburg) for rescuing my dead shifter levers this summer. The iPhone 12 for being such a reliable adventure camera.

(1) Appendix: full 392km / 6500m route on Strava (ride at your own risk)

Day 1: 88km / 1400m. Salzburg to Maria Alm am Steinernen Meer over Dienten am Hochkönig and Dienter Sattel

S1 Hochkönig | 85.6 km Cycling Route on Strava

Day 2: 128km / 3200m. Maria Alm to Lienz in Osttirol over the Glocknerstraße and Paß Iselberg

S2 | 125.9 km Cycling Route on Strava

Day 3: 176km / 1800m. Lienz to Salzburg over Felbertauernstraße and Klausbachtal.

• S3E01 Zum Felbertauerntunnel | 47.2 km Cycling Route on Strava
• S3E02 Epilogue | 130.4 km Cycling Route on Strava

(2) https://www.salzburg24.at/news/oesterreich/grossglockner-hochalpenstrasse-salzburgerin-stirbt-nach-fahrrad-unfall-139589563

If you’re new to undercover, make sure to visit https://undercover-ci.com for more info, or read the getting started guide.

I was recently contacted by Aleksandr in this GitHub issue for pronto-undercover who proposed making undercover warnings less strict with configurable required percentage. After all, pull requests in projects with low or nonexistent initial test coverage can likely generate large numbers of hard-to-deal-with warnings which you might not want to address all at once. This was the case for the issue author.

You can set the undercover PR check to optional, which I normally recommend, but it won’t fix the noise generated by a poorly tested codebase.

Should you then just rely on a global coverage threshold (e.g. SimpleCov.minimum_coverage) that allows more wiggle room, e.g. 50%? I don’t think so, because random lines might slip through review and make bugs more likely to happen. But, I recently found out about a better and more explicit test coverage strategy thanks to SimpleCov.

✨ SimpleCov lets you wrap any Ruby code in :nocov: comments to disable coverage reporting, which also works great for suppressing any undercover warnings. I didn’t know about this. ✨

# :nocov:
def skip_this_method
  never_reached
end
# :nocov:

As I wrote earlier, my general undercover CI workflow was to set undercover as an optional check, so that anyone can merge changes even when some acknowledged lines and methods are missing tests. It’s good, because these are surfaced and scrutinized in code review.

But what about this strategy instead:

• mark the coverage pull request check as required instead of optional
• in case you want to acknowledge and skip a particular warning, update the code and tag relevant lines with :nocov:(could be fully automated by UndercoverCI with repo write permission in the future!)
• only ship on green, with potential untested lines flagged and silenced

Why? This way information loss is avoided and your future self (and team) will clearly know which code parts went to production untested thanks to all the :nocov: comments.

Let me know what you think about this. Will you ever get back to those comments to fix them? 😅 Did you know about this handy SimpleCov feature? Maybe it’s a good idea to update your test coverage strategy to allow untested changes only when wrapped in :nocov: blocks.

📚 The :nocov: syntax has now a dedicated section in UndercoverCI docs: skipping/ignoring coverage.

This addition allows you to detect even more untested code within each automated pull request review, including untested case statements, conditional method calls (e.g. foo&.jump), single-line ifs (return :foo if valid?) or ternaries (foo ? 1 : 2).

Head over to the readme if you’re getting started, otherwise here’s what to do to add branch coverage reporting to a pre-existing undercover or UndercoverCI project setup:

1️⃣ Ensure your test command reports coverage using simplecov >= 0.18.0 and simplecov-lcov >= 0.8.0

2️⃣ Add enable_coverage(:branch) to the simplecov configuration block in spec_ or test_helper.rb:

SimpleCov.start do
  enable_coverage(:branch)
end

3️⃣ That’s it! From now on, your checks will pick up and flag any untested code branches, plus you’ll see the total number of branches per method in the UndercoverCI check summary. 🤙🕵

This is how it looks in a sample check result from UndercoverCI (GitHub App):

And that’s a sample branch coverage result from undercover CLI:

On a closing note, this addition to undercover was possible thanks to PragTob who added branch coverage to SimpleCov and Magne Land’s contribution to the branch cov feature in Undercover. Thank you! ❤️

What?

Adding UndercoverCI to your code review workflow will prevent untested code changes from slipping into production without anyone noticing.

UndercoverCI is a GitHub App for Ruby that finds untested code changes in your commits and pull requests by reading each diff and comparing against a test coverage report. The result: actionable comments on untested methods, classes and blocks, whereas other coverage tools would only give you percentage data.

Why is that better than $my_current_coverage_tool?

I’ve written about why you should stop shipping untested Ruby code with undercover and how to wire it up with your workflow when I released undercover — the core gem that actually powers UndercoverCI (470+ stars on GitHub and counting!).

Here’s a TLDR. You should consider UndercoverCI if:

• You think that aiming for full test coverage might not be the best investment for your team, but want to ensure all pull requests are well-tested.
• You’d like to encourage your team to write more robust tests and increase test coverage where it matters and at the right time.
• You’d rather automate such code review comments (my coworkers’ real replies to undercover):

Actually the tests weren’t even calling the code I’ve changed.

, or:

Looks like this branch was never tested…

To recap the above points, existing coverage tools for Ruby provide percentage data and diffs, yet they guarantee that all committed lines are covered only if you hit 100% or review the test coverage report manually before each merge. You can automate that effort with UndercoverCI and get PR checks that look like if someone has searched for missing tests in the SimpleCov report. This makes it useful for projects scoring below 100% coverage or ones that won’t give you the confidence of a comprehensive test-suite at all. It’s a focused and local approach, which ensures that you invest in test coverage where it matters most.

🕵️‍♀️ Ok, sign me up!

If you’re convinced, sign up on the UndercoverCI website or go straight to UndercoverCI on GitHub to install the app!

How much does it cost? Yes it’s going to be a paid product with a monthly subscription starting at about $29 (exact pricing TBD). Good news is that you can still get it for free if you sign up before 2020–07–31!

Ruby’s SimpleCov lets us track test coverage and is common when developing Ruby on Rails apps. Many code review services that rely on SimpleCov allow us to see the coverage delta or diff coverage as a percentage. I’ve been recently talking to Ruby developer friends and gathering feedback about an alternative approach, which is to turn untested code into actionable pull request warnings, because coverage as percentage is insufficient.

This post will teach you how to get started with Undercover. We’ll set it up locally, so that commits are blocked until we have tests in place. Then, we’ll learn how to add a code build status check in CI services and finally, how to post automated review comments to GitHub using Pronto.

It’s almost Christmas, so let’s get started and give our Ruby projects some love!

Getting started with local coverage checks

Setup

First fetch the gem from RubyGems with:

gem install undercover

Once installed, the undercover command should be available to your system. However, to make it fully functional we need to set up test coverage tracking.

Update your Gemfile with SimpleCov and an LCOV reporter, which is Undercover’s coverage input file format:

gem 'simplecov'
gem 'simplecov-lcov'
gem 'simplecov-html' # if you'd like classic html coverage reports

After installing them with bundle install, we enable coverage tracking at the very top of the test_helper.rb or spec_helper.rb, before any of the application code is required.

require 'simplecov'
require 'simplecov-lcov'
SimpleCov::Formatter::LcovFormatter.config.report_with_single_file = true
SimpleCov.formatter = SimpleCov::Formatter::MultiFormatter.new([
  SimpleCov::Formatter::LcovFormatter,
  SimpleCov::Formatter::HTMLFormatter,
])
SimpleCov.start do
  add_filter(/^\/spec\//) # For RSpec  
  add_filter(/^\/test\//) # For Minitest
  enable_coverage(:branch) # Enables branch coverage
end

To verify the above set up, we can now run specs and see that a nonempty coverage/ directory has appeared in the project root.

Using the CLI

When undercover is invoked with no arguments, the command-line interface inspects the most recent coverage report and looks for untested methods that appear in the current changeset. What are these methods exactly? These are all code blocks that have any source lines appearing in the current git index (staged) and work tree (unstaged). Let’s illustrate that with an example.

Assuming no changes have been made since last commit, undercover prints out a message and exits cleanly.

$ undercover
✅ No reportable changes
Undercover finished in 0.0742s

The fun begins when we start making changes to our code and test suite. Let’s assume we change a method, run our test suite and invoke undercover again. Now, we get a different output:

Whoops! We need to add tests to the validate instance method to keep Undercover happy. If we add those and run undercover again, we’ll be back to green.

Compare to branch or commit

We have analysed test coverage for the current diff, but what about bigger chunks of work? Undercover can perform the same analysis with respect to any branch or commit. This is where the -c or --compare option comes in handy.

Try this set of command arguments:

undercover --compare master

It will look at the most recent coverage report and find untested methods in the entire diff between HEAD and what we’ve set in --compare. Comes in handy for various branching workflows!

Automate

We now have what we need to create the beginning of an automated feedback loop. Let’s get started with git hooks.

What are they? Git hooks are customisable scripts that live in .git/hooks of every repository and are executed before or after git events. They can be edited manually, but I suggest to start with a helper gem called overcommit, which does an excellent job managing community standard git hooks and custom ones.

Follow Overcommit’s readme to install it and place the contents of this suggested config in .overcommit.yml. An starter config should have been created during installation.

PrePush:
  Undercover:
    enabled: true
    required: true
    command: ['undercover', '--compare', 'master']

This is my config of choice that ensures all tests are in place before code is pushed (PrePush). You might want to change this to suite your preferences and perhaps use a PreCommit variant instead. It’s also good to know that hooks can be disabled in an emergency by setting OVERCOMMIT_DISABLE=1 or using the --no-verify option in commands like commit or push.

Set up Continuous Integration

The next steps will cover adding Undercover to analyse commits project-wide on the CI server, so that we close the feedback loop and make it part of the code review process.

Step 1: Build status check

We’ll start with a status check for test coverage that runs tests and then Undercover. I have prepared a few starter configs for a few popular CI services: Travis CI, CircleCI, Semaphore and Codeship. They are also stored in the repo in case you need them later.

GitHub Actions

The sample workflow config was taken straight from the undercover repository. It fails the build based on coverage results and failures can be inspected within the output log. This is not ideal, but works just fine.

# .github/workflows/ruby.yml
name: Rails Unit Tests
on: [push, pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Set up Ruby 3.2
      uses: ruby/setup-ruby@v1
      with:
        ruby-version: 3.2
    - name: Build and test with Rake
      env:
        RAILS_ENV: test
      run: |
        # other pre-requisite setup steps...
        gem install bundler undercover
        bundle install --jobs 4 --retry 3
        bundle exec rake test
        undercover --compare origin/master

CircleCI

Sample single-job config for CircleCI that runs specs and validates coverage with Undercover.

# .circleci/config.yml
version: 2
jobs:
  build:
    docker:
      - image: circleci/ruby:2.5-browsers
    steps:
      - checkout
      - run:
          name: Install dependencies
          command: |
            sudo apt-get install cmake
            bundle install
      - run:
          name: Run RSpec
          command: bundle exec rspec
      - run:
          name: Check coverage
          command: |
            gem install undercover
            undercover --compare origin/master

We can go even further and create a separate job for analysing coverage, leveraging features of CircleCI 2.0. That is useful, because we can benefit from workflows and build conditions, but requires a bit more work. Having that in mind, there is another more advanced starter config available on GitHub, where the LCOV report file is shared between multiple CircleCI jobs to create individual build stages for test and coverage.

Semaphore

Semaphore pipeline example with a single job running rspec and undercover:

version: v1.0
name: RSpec + Undercover
agent:
  machine:
    type: e1-standard-2
    os_image: ubuntu1804
blocks:
  - name: "RSpec"
    task:
      jobs:
      - name: Run Specs and Check Coverage
        commands:
          - checkout
          - bundle install
          - bundle exec rspec
          - gem install undercover
          - undercover --compare origin/master

Codeship

To run specs and analyse coverage in Codeship, go to Project Settings and place the following instructions in the Setup Commands section:

rvm use 2.5.3 --install
bundle install
gem install undercover

Then, run specs and undercover as part of the Test Pipeline:

bundle exec rspec --format documentation --color
# pull origin/master to have a ref to compare against
git remote set-branches --add origin master
git fetch
undercover --compare origin/master

One caveat is that Codeship uses a shallow git clone, so we need to specifically add the master branch (or any other branch we want to compare with) to the cloned repository. This way we can use undercover --compare origin/master.

Merging test results from multiple test runners

Another common caveat that applies to most CI services supporting parallel execution is about partial test results. Undercover does not currently support partial coverage reports, so we need to merge them into one before running the undercover command. If this applies to you, this gist might be a good starting point.

Step 2: Automated GitHub comments

We have already closed the feedback loop with the build status, but that’s not all we can do. How about not having to inspect the build output every time untested code is detected? We can create automated pull request comments thanks to Pronto and its integration with Undercover!

Pronto is an open-source automated code review framework that integrates with multiple tools (Rubocop, Reek, Brakeman included) and offers integrations with SCMs like GitHub, GitLab and Bitbucket.

To start setting up review comments, we need a GitHub API OAuth token. It’s up to you to create a new bot user account or use a personal one. Either way, please sign in to GitHub and go to Settings → Developer Settings → Personal Access Token. Then click on “Generate New Token” illustrated below.

Let’s create a token with repo or public_repo privilege scope and make it available to the CI environment. From now on we’ll use Codeship as an example, but these instructions should require minimal changes no matter which CI you are using.

To set build environment variables in Codeship, visit Project Settings → Environment and specify each new variable as a key value pair. Please note that Pronto expects the variable holding our access token to be named PRONTO_GITHUB_ACCESS_TOKEN.

Next, we need update the setup instructions to install pronto and pronto-undercover gems instead of just undercover. This is how the Setup Commands section should look like:

# Setup Commands
rvm use 3.2.0 --install
bundle install
gem install pronto
gem install pronto-undercover

Then, modify the Test Pipeline to run tests and then analyse coverage with pronto. We will use the github_pr formatter option to enable the GitHub integration.

# Test Pipeline
bundle exec rspec --format documentation --color
# pull origin/master to have a ref to compare against
git remote set-branches --add origin master
git fetch
pronto run -f github_pr -c origin/master

Now, when we save our changes, re-run the build and Pronto triggers any coverage warning, it will create comments in GitHub instead of failing the CI build. Yas!

Summary

After reading this post you should know how to:

1. Set up the undercover gem to run locally, so that untested code changes do not escape the development environment
2. Configure your CI to do the same thing, but across all commits and remote branches
3. Create an automated code coverage feedback loop with Pronto and code review comments that appear directly in a GitHub pull request diff.

I hope Undercover will help you deliver better and well tested code with more confidence! If you have any feedback or run into issues with any of the presented setups, please leave comments below, create a GitHub issue or get in touch with me.

Happy Holidays!

And don’t forget to leave a ⭐️ at https://github.com/grodowski/undercover. Also make sure to check out the Undercover GitHub App, which is free to use for public repos: https://undercover-ci.com.

Undercover inspects changed files and creates warnings for blocks of code which have not been tested, similar to a linter. It’s a simple idea I found useful in a large codebase along with existing coverage reporting tools and I hope you’ll see the value as well!

Testing large apps

Dealing with large inherited (legacy?) codebases carries a risk of breakage. That’s why we write tests in the first place. Every programmer is probably guilty of a bug or service outage caused by that tiny change, because it is so easy to miss a side-effect or edge case especially when we are new to a project.

The test suite in place may be subpar. There is no guarantee that the assumptions it makes are correct. Worst case it might not exist or be incomplete.

I have worked with such projects and used to be an advocate of always aiming for full test coverage. However, reality verified that quickly. Testing code created months or years ago by another person (who might have already left the company 😱) results in brittle tests that usually fail to capture the complexity or all edge scenarios. In other cases, it ends up becoming an endless effort of reverse engineering actual production code that works just fine for its purpose.

So is 100% test coverage actually a goal worth hitting? No, it’s usually not! I’d like to propose a different approach to measuring and improving coverage for large apps, so that we can live peacefully with legacy code and spend more time working on meaningful features.

Write tests at the right moment

Undercover is a code review utility that takes the ideas from code quality tools like RuboCop or Pronto and applies them to coverage. If 100% test coverage is not what we want to invest our time in, how about making sure that just the code in scope of our changes is tested well?

Undercover does that and triggers warnings on untested parts of our code based on a changeset from git and a set of rules. Take a look at a sample output below, where undercover checks a recent change in undercover 🙀.

Those warnings are a complementary input to code coverage as percentage or percentage delta in case of pull requests. Why? Firstly because timing matters: Undercover’s goal is to turn code review comments like this…

…into automated feedback that should be addressed before actual code review (involving human) starts. It doesn’t care whether you write tests before or after the implementation, but makes sure they are in place before code is merged.

Additionally, it is less prone to false green results. A false green result is a message like “your code coverage has improved by 1%”, when it’s sometimes enough to add some new well-tested code to skew the result and sneak in some untested methods. This approach is also insensitive to code deletions, which may cause fluctuations in code coverage measured as percentage.

How it’s made

Undercover fuses data from a git repository (rugged), a coverage report (simplecov) and a parsed representation of your Ruby code.

Each line taken from a git diff may trigger a warning if it has been added or modified. Then, the selected candidate source lines are matched against the latest coverage report to check if they have been hit at least once in tests. Finally, warnings are generated for respective code blocks (methods, classes, modules and blocks) that encompass untested source lines.

There’s more to come 🏗

Undercover is still an experiment in its early days. However, we are using it in the CI/CD pipeline at Rainforest QA and it has already given some useful feedback on our pull requests! Now it’s time to explore where to take it next and these are some ideas I would like to work on.

Better feedback loop

A good workflow integration is a must have and can be achieved through a Pronto plugin as well as a Code Climate engine. Both will have the capability to provide users with faster feedback from CI and are on my list. The pronto runner is already in the works!

Run modes

Undercover warnings are currently derived from changed source lines. But what if the line below is still untested and is waiting to cause an error? Or even worse, what if the total coverage of the file I just modified is really poor? My idea for that is called “Run Modes”. They expand the range of candidate source lines to all adequate locations to minimise the error inherent in coverage measurements. Two new modes would report on changed code blocks or changed files instead of just source lines, hence fostering proactive coverage improvements for methods/blocks/files we touch in our changes.

Coverage data quality

Branch coverage is a new addition to Ruby available in 2.5+ or through the DeepCover gem, while the covered gem can provide coverage warnings for evaluated code like view templates. Incorporating them into the gem would help detect brittle tests and reduce false greens. You might also want to check out this Ruby core issue with an interesting discussion on where branch coverage is heading.

I’d love to hear your thoughts about Undercover’s approach to measuring code coverage. Does it fit into your current testing strategy? If you like the idea, go visit undercover on GitHub, press the star button ⭐️ and try it out for your Ruby project. Happy testing!

Stop shipping untested Ruby code with undercover was originally published in [:] futureDev on Medium, where people are continuing the conversation by highlighting and responding to this story.