coordination #93883: [epic] Speedup openQA coverage tests with running minion jobs synchronously using new upstream "perform_jobs_in_foreground" mojo function
Increase code coverage of critical component OpenQA::Worker::Job without introducing slow-down due to subprocess coverage collection
https://codecov.io/gh/os-autoinst/openQA/src/master/lib/OpenQA/Worker/Job.pm currently reports a statement coverage of 77% which is below our average. Similar as in the parent #93883 we are using subprocesses with Mojo::IOLoop suffering from the same problem as minion jobs: Collecting coverage in system-level tests is hard and if we ask Devel::Cover to collect coverage then it can be quite slow. Better if we have explicit unit-level testing for code intended to run in subprocesses and/or run subprocesses as synchronous foreground code.
- AC1: Code coverage of https://codecov.io/gh/os-autoinst/openQA/src/master/lib/OpenQA/Worker/Job.pm is significantly higher than the current 77%
- AC2: Tests like t/24-worker-jobs.t still run fast, e.g.
make coverage TESTS=t/24-worker-jobs.ttakes less than 30s locally
make coverage KEEP_DB=1 TESTS=t/24-worker-jobs.tlocally
- Extend the current test coverage before applying any changes
- Refactor to simplify OpenQA::Worker::Job
- Review the design regarding the use of subprocesses
I can try. Here's another PR for a slight improvement: https://github.com/os-autoinst/openQA/pull/4040 - This leaves only the functions
_log_upload_error which is used by them) completely uncovered.
_upload_asset is now covered as well.
With that the file's coverage is now at 99.55 % which is actually quite good. The few remaining lines would be possible to cover as well but of course the effort/benefit ratio is much worse (as they're spread over different functions/branches).