I’m an intern at Geotab tasked with fixing a hack used in my company's continious integration and development testing.
To briefly explain, Geotab is a telematics company focused on providing fleet management solutions for both private and public sector organisations. The company utilises Coverlet to assist with its continuous integration and development, primarily calculating and tracking unit test coverage as per Coverlet's design.
The problem encountered with the incorporation of Coverlet is the needlessly redundant processing when jobs are parallelized. Specifically, the execution of the unloading of instrumentation and aggregation of Coverlet’s test coverage result.
Since instrumentation unloading and Coverlet’s result aggregation are set to always occur one after the other, parallelized jobs will run multiple instances of report generation simultaneously, these results would then be used to further report generation to aggregate the already aggregated results.
As such, the simultaneous report generation is an unnecessary process as one instance of report generation can be run instead, rather than the multiple in parallel that require the further aggregation anyways.
GeoTab’s Hack
The hack implemented by my supervisor, then, is to invoke the unloading of instrumentation using the .Net Reflection library. This hack is similar to the one used in Coverlet's VSTest Platform integration as noted here.
Problems with the Hack
The main problem with this hack is the long term maintenance of Geotab’s Coverlet integration. Unlike the VSTest integration, any changes to Coverlet involving the unloading of instrumentation may result in numerous undetectable issues for Geotab.
As such, Geotab, and many users who utilise parallelization, would benefit from Coverlet being able to work more seamlessly with systems, projects and others using parrellism in code testing.
Desired Change Results
The goal of these changes are as follows:
Enable developers to invoke a method to unload instrumentation of assemblies
Maintain existing execution operations for testing in projects that are still executed serially
Add required unit tests to ensure functionality
Fell free to ask me any questions if something is unclear.
Dear Coverlet Team,
I’m an intern at Geotab tasked with fixing a hack used in my company's continious integration and development testing.
To briefly explain, Geotab is a telematics company focused on providing fleet management solutions for both private and public sector organisations. The company utilises Coverlet to assist with its continuous integration and development, primarily calculating and tracking unit test coverage as per Coverlet's design.
Associated issue with this PR: https://github.com/coverlet-coverage/coverlet/issues/1694
The Problem
The problem encountered with the incorporation of Coverlet is the needlessly redundant processing when jobs are parallelized. Specifically, the execution of the unloading of instrumentation and aggregation of Coverlet’s test coverage result.
Since instrumentation unloading and Coverlet’s result aggregation are set to always occur one after the other, parallelized jobs will run multiple instances of report generation simultaneously, these results would then be used to further report generation to aggregate the already aggregated results.
As such, the simultaneous report generation is an unnecessary process as one instance of report generation can be run instead, rather than the multiple in parallel that require the further aggregation anyways.
GeoTab’s Hack
The hack implemented by my supervisor, then, is to invoke the unloading of instrumentation using the .Net Reflection library. This hack is similar to the one used in Coverlet's VSTest Platform integration as noted here.
Problems with the Hack
The main problem with this hack is the long term maintenance of Geotab’s Coverlet integration. Unlike the VSTest integration, any changes to Coverlet involving the unloading of instrumentation may result in numerous undetectable issues for Geotab.
As such, Geotab, and many users who utilise parallelization, would benefit from Coverlet being able to work more seamlessly with systems, projects and others using parrellism in code testing.
Desired Change Results
The goal of these changes are as follows:
Fell free to ask me any questions if something is unclear.