Your test configuration
TestDetta narrows your test runs. It never widens or changes them: a test your configuration excludes stays excluded, and coverage maps are recorded under your own settings.
What TestDetta adds to a run
- A class filter when only some test classes run:
--filter FullyQualifiedName~…under VSTest,--filter-classfor xUnit v3 and--treenode-filterfor TUnit under Microsoft.Testing.Platform. - Run settings while recording: one test at a time, no test AppDomains, and the collector that records coverage.
--ignore-exit-code 8for the part of a recording that may find no test, under Microsoft.Testing.Platform.
What TestDetta keeps
Left alone, dotnet test lets some of these replace your own configuration. TestDetta combines them instead:
| Your configuration | What dotnet test alone would do | What TestDetta does |
|---|---|---|
VSTestTestCaseFilter in the project file, such as Category!=Integration | A --filter on the command line replaces it: excluded tests run | Runs (your filter)&(its class filter) |
--filter in your own dotnet test arguments | Takes one --filter only | Runs (your filter)&(its class filter) |
A run settings file (RunSettingsFilePath, VSTestSetting or your --settings): its TestCaseFilter, EnvironmentVariables, TestRunParameters, data collectors, timeouts | Another --settings replaces the whole file | Records under a copy of your file with only its own elements added; your filter, variables and parameters stay |
TestingPlatformCommandLineArguments (Microsoft.Testing.Platform), such as --filter-not-trait category=failing | Applies it to every run | Leaves it to the platform, and does not repeat an option you already set once |
When a selected project runs completely, TestDetta adds no filter, and your configuration applies exactly as in your own runs.
Give TestDetta your CI's arguments
Pass the same dotnet test arguments your own test job uses, both when tests run and when maps are recorded:
td test --base origin/main -- --filter "Category!=Integration" --settings ci.runsettings
td record -- --filter "Category!=Integration" --settings ci.runsettingsIn GitHub Actions, the dotnet-test-args input does this in every mode, record mode included. Options a recording controls itself (-c, -f, --no-build, loggers, the results directory and report options) keep TestDetta's values while recording; everything else runs as you give it.
A -f <tfm> among the arguments of td test also narrows the selection: the run loads only that framework's builds, so a change compiled only for other frameworks (code under an #if that framework leaves out) selects nothing in it. If your test projects target several frameworks, run every framework somewhere, for example in a nightly full run; see Limitations.
When a filter cannot be combined
Some filters cannot be joined with a class filter: an xUnit v3 query filter (--filter-query) or class filter of your own, and a TUnit tree-node filter. TestDetta then runs the whole test project under your filter: it runs more, never what your filter leaves out. The job summary says so for that project.
Check what was kept
Before the tests run, the console names each test project whose own configuration was kept, for example tests/Shop.Tests/Shop.Tests.csproj: your test case filter Category!=Integration, run settings tests/ci.runsettings kept in every run. The job summary lists the same, and -v writes the exact dotnet test command of each run.
If your build or CI sets test arguments in a way not listed here (an Arcade property, a wrapper script around dotnet test), pass them through dotnet-test-args or after --, so TestDetta sees what your runs really do.