-
Notifications
You must be signed in to change notification settings - Fork 998
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
Increase code coverage #917
Comments
We have a user epic issue tracking functional testing parity with Core. #672 We have about 100-200 apps which are used in testing automation using Maddog in the .NET FX, and we've had an enormous backlog item to get them driven by xunit and incorporated into our CI. As far as I know, this will not change the number above representing our Code Coverage but it will increase the surface area over which we test. @sharwell may have a better idea about that. |
For tracking down the areas for our code coverage, if you click any of the buttons for code coverage on the top-level README here: https://github.com/dotnet/winforms#code-coverage You will be directed to an interactive dashboard showing what parts of our code have coverage in xunit tests. https://codecov.io/gh/dotnet/winforms In particular, the outermost rings of the sunburst chart may be what you are looking for. Click on it For example, here is the sunburst for System.Windows.Forms src: I would also recommend looking through the files tab https://codecov.io/gh/dotnet/winforms/tree/master/src For example, by exploring the Files, you can hone in on that although System.Windows.Forms.Design has very low code coverage, that low code coverage is not really in Drawing/Design |
Superseded by another item - #10453 |
I didn't see an issue for this already (feel free to close if there is one). Looks like coverage is less than 30%.
@hughbe you've spent more time looking at the code/tests than many of us, how feasible do you think it is to get this number up? That would help increase confidence in the upcoming release, for sure - and make refactors less risky.
I wonder if the debt could be categorized somehow eg by namespace to make this easier to drive.
The text was updated successfully, but these errors were encountered: