-
-
Notifications
You must be signed in to change notification settings - Fork 46
Mscodecoverage #245
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mscodecoverage #245
Conversation
@mschnelte Thanks. WIll have a look tomorrow. |
@mschnelte Adding some commits now |
… to MsCodeCoverageRunSettingsService
There are additional issues with this pr. FCC currently outputs cobertura files to a specific directory - this should follow suit. It does not work well with a test project that provides its own run settings - of course you can set the option to false - but then you are not getting the benefit. The code should only be creating run settings when required and should be able to collate output files for either scenario. PrepareCoverageProjectsAsync is being unnecessarily called. At the moment only the test assembly is excluded ( all in one runsettings to be used by all test projects ). FCC does more than that. I have the code that I used to demonstrate the idea ( #214 (comment) ) that can be merged with your existing code. It also refactors FCCEngine so that FCCEngine is ignorant to ms coverage. Please don't add any further commits until I have addressed these issues ( tomorrow now ). |
I am aware of it. But aren't the settings in FCC coverlet specific? If you feel it's worth the trouble mapping them feel free to do this. For me it would be good enough to edit the fineCodeCoverage.xml template as stated in the description of the PR. What I do not like about the FCC options is the fact that they are not solution specific. Using the template for that would make it solution specific. I would favor that over global options. But of course nothing is stopping us to mix both approaches.
What you are showing there was how I started. Simply collecting the coverage files if runsettings are set. I guess that is a use case that should be supported. But don't forget that runsettings might not contain a CoverageCollector - and I guess that is currently the majority of runsettings given the fact how new the microsoft code coverage support is. In those cases the user's runsettings might need to be altered to include coverage. One workflow could be:
|
Sorry for not responding today but I have been dotPeek-ing the test explorer source looking for the optimum solution. |
No worries. I will most probably not be very responsive either until beginning of next week. |
Hopefully tomorrow I will be able to show the changes that I have made. |
There is more that I will do in the next couple of days. Committing now that you can see where I am going with this. This now works if the dev provides runsettings or not. If not then runsettings are created for each project with includes / excludes being determined in a similar manner to pre ms code coverage. I have added new FCC options that can be provided globally or on a project basis as before. ( I will add the concept of solution options that will apply to ms code coverage and the old way soon ). If desired a template can be provided ( found by naming convention in project / solution folder ) that will be used with string replacement as before. If the dev provides runsettings this can also participate in string replacement. |
…wtonsoft.Json as nuget package as advised
released v1.1.170 and available on marketplace |
Adding support for microsoft's code coverage.
Can be enabled via options.
Coverage settings are controlled via fineCodeCoverageSettings.xml file that is created on first test run if ms code coverage option is enabled.