At Very Good Ventures, we are passionate about writing tests for our codebases — in fact, we strive for 100% test coverage on all of our projects. To ensure that we can maintain this threshold with any new lines of code that we write, we created Very Good Coverage, a GitHub Action that supports multiple operating systems to enforce a code coverage threshold.
By adding the below lines to the GitHub Actions workflow, you can enforce a minimum coverage threshold of your choosing (we recommend sticking with the default setting of 100%, but feel free to change to a number that best works for you and your project). You can also exclude files, such as generated code, from the calculation.
We highly recommend adding Very Good Coverage to new and existing projects to ensure all code contributions are being tested.
- For new projects: We recommend keeping the default min coverage of 100% for maximum confidence that every single line is covered.
- For existing projects: Generate an lcov coverage report, then use the current coverage from that as the minimum coverage for Very Good Coverage. This will ensure that the code never drops below the existing percentage. Each sprint, try to make it a goal to gradually increase the percentage until you reach 100%!
How We Built It: Four Nights of “Live” Coding
If you want to see exactly how we built Very Good Coverage, we recorded the entire process from planning to publish. In early October, we set out to create a series of #VeryGoodOSS videos for the Chicago Flutter Meetup Group that would showcase our love for the open source community and premiere during DigitalOcean’s Hacktoberfest.
We compiled all of the videos in this Very Good Open Source Playlist! A recap of what we accomplished each day:
Day One: Planned the scope of the project and the tasks we needed to complete.
Day Three: Continued building functionality.
Day Four: Cleaned up the code and published the package.
While lcov-cop originally lived under the Chicago Flutter organization, we shifted it to Very Good Open Source because we use it a lot on internal VGV projects and knew it would be easier to maintain there.