Consolidate System.Private.Xml test projects #75499
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-xml Issue DetailsWe currently have almost 30 test projects underneath System.Private.Xml\tests in various levels of nested directories. This makes it challenging to appropriately run all of the System.Private.Xml tests when making any changes to anything in S.P.Xml, and it makes it all but impossible to get meaningful code coverage information, which in turns significantly lowers our confidence about any changes being made to the library. This PR consolidates almost all of them into a single System.Private.Xml.Tests projects. It is a mostly mechanical change, adding all of the relevant files to the single .csproj and deleting the individual csproj files. In some cases I added more specific namespaces to deal with conflicts. In others multiple projects were including the same files containing [Facts] and parameterizing them via statics that were supplied by individual files built only into the relevant projects; I fixed those by making the [Fact]s into [Theory]s and passing in all the relevant state. I also had to fix up some cases where tests were mutating global state that then conflicted with other tests. This explicitly does not:
I did run the fixer to remove unnecessary usings, as I’d added some usings as part of mechanically fixing this without paying attention to whether they were necessary or not. There are just two test projects that remain separate: one for trimming, and one for serialization that runs some of the same tests but with a different compilation constant set for its build. Fixes #75456 Resulting code coverage is now measurable but not great:
|
ghost
assigned
Is the default xunit parallelization disabled? |
Yes. A bunch of the tests change process-wide state, e.g. setting various AppContext switches. |
|
Is this going to increase end to end test time then, as previously each library would potentially run concurrently with the others? |
Considering the significant overhead associated with running a test suite in CI, I highly doubt it. |
src/libraries/System.Private.Xml/tests/XPath/XPathDocument/System.Xml.XPath.Tests.csproj
Outdated
Show resolved
Hide resolved
How many tests do this? Would it be feasible to use RemoteExecutor for those in a later change? |
Yup. |
|
I need to make some fixes to the xml linq test project which apparently pulls in some of the same shared files... |
We currently have almost 30 test projects underneath System.Private.Xml\tests in various levels of nested directories. This makes it challenging to appropriately run all of the System.Private.Xml tests when making any changes to anything in S.P.Xml, and it makes it all but impossible to get meaningful code coverage information, which in turns significantly lowers our confidence about any changes being made to the library. This PR consolidates almost all of them into a single System.Private.Xml.Tests projects. It is a mostly mechanical change, adding all of the relevant files to the single .csproj and deleting the individual csproj files. In some cases I added more specific namespaces to deal with conflicts. In others multiple projects were including the same files containing [Facts] and parameterizing them via statics that were supplied by individual files built only into the relevant projects; I fixed those by making the [Fact]s into [Theory]s and passing in all the relevant state. I also had to fix up some cases where tests were mutating global state that then conflicted with other tests. This explicitly does not: - Clean up any test code beyond the minimal necessary to get this to compile. Many of these tests are old and crusty and worthy of a complete rewrite, but I restrained myself. - Move or rename any files around. - Try to enable parallelization of the tests. That’d be good to do at some point to help with test execution time, but I didn’t want to change any tests beyond what was necessary. I did run the fixer to remove unnecessary usings, as I’d added some usings as part of mechanically fixing this without paying attention to whether they were necessary or not. There are just two test projects that remain separate: one for trimming, and one for serialization that runs some of the same tests but with a different compilation constant set for its build.
stephentoub
force-pushed
the
xmltestconsolidation
branch
from
13bae50 to
9474066
Compare
4 participants
We currently have almost 30 test projects underneath System.Private.Xml\tests in various levels of nested directories. This makes it challenging to appropriately run all of the System.Private.Xml tests when making any changes to anything in S.P.Xml, and it makes it all but impossible to get meaningful code coverage information, which in turns significantly lowers our confidence about any changes being made to the library.
This PR consolidates almost all of them into a single System.Private.Xml.Tests projects. It is a mostly mechanical change, adding all of the relevant files to the single .csproj and deleting the individual csproj files. In some cases I added more specific namespaces to deal with conflicts. In others multiple projects were including the same files containing [Facts] and parameterizing them via statics that were supplied by individual files built only into the relevant projects; I fixed those by making the [Fact]s into [Theory]s and passing in all the relevant state. I also had to fix up some cases where tests were mutating global state that then conflicted with other tests.
This explicitly does not:
I did run the fixer to remove unnecessary usings, as I’d added some usings as part of mechanically fixing this without paying attention to whether they were necessary or not.
There are just two test projects that remain separate: one for trimming, and one for serialization that runs some of the same tests but with a different compilation constant set for its build.
Fixes #75456
Resulting code coverage is now measurable but not great: