Fix cucumber coverage
Summary
The code coverage collection of cucumber features was broken. This pull request fixes it.
Before applying this change, running bundle exec cucumber against the aruba main branch resulted in the following message being written to the console:
Coverage report generated for Cucumber Features to ./coverage. 0 / 0 LOC (100.0%) covered.
After applying this change, running bundle exec cucumber results in the following message being written to ./coverage/summary.txt:
Coverage report generated for Cucumber Features, [...list of features that were executed...] to ./coverage. 2375 / 2776 LOC (85.55%) covered.
Details
This was fixed by applying a few different changes:
- The mechanism for modifying the
RUBYOPTenvironment variable was changed to useprepend_environment_variable. - A
Beforehook was replaced with anAroundhook that callswith_environmentto preserve environment variable changes. - The mechanism for enabling coverage collection for sub-commands was changed slightly so that the file could be reliably required via the
RUBYOPTenvironment variable. - The
simplecov-htmllibrary was monkey-patched to work around its lack of support for suppressing the output that it generates. This was required to ensure that features pass when they are looking for the exact output of a command. - Timing values were changed in several features to account for the extra time required for Simplecov to do its work. The
simplecov-htmlgem has an open issue that when fixed would likely permit the removal of this monkey patch. See simplecov-ruby/simplecov-html#116 for more information.
Motivation and Context
I was working on measuring code coverage for another project that I'm working on which uses aruba to test a Ruby-based CLI application. I noticed that the aruba codebase appeared to support code coverage collection via simplecov, so I used the aruba configuration as a starting point. When I discovered that the coverage collection was not working in that gem, and I later discovered that coverage collection was also failing the same way in the aruba repository, I dug in and figured out how to resolve the issue. That effort can be examined further by looking at CycloneDX/cyclonedx-ruby-gem#21.
How Has This Been Tested?
No changes were made to core aruba code, only the Simplecov integration and some timing values in features that rely on wait timeouts. All tests were passing locally (multiple times in a row) before opening the pull request. The situation may be different when things are run in a CI environment.
Types of changes
- [x] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
- [x] Internal change (refactoring, test improvements, developer experience or update of dependencies)
Checklist:
- [ ] I've added tests for my code
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
I'm pretty sure that none of the above :point_up: apply to this change. Please let me know if I'm wrong.
I suspect that some of the changes in this pull request might benefit from the work that's being done in #894. Would it make any sense for me to lend a hand on #894 or is that a task that's best tackled by one person?
@mvz is there anything else that you can think of that this work needs before it can be merged in?
I'll fix the linter issues later today.
@mvz Linter issues should be all fixed now.
I'm fixing the unrelated RuboCop offense in a different pull request.