filter-syntax
Reference-only filter syntax for VSTest and MTP with MSTest, NUnit, xUnit v3, and TUnit. Load only after the platform/framework is known and a consumer needs to create or translate a filter. Do not load for unfiltered runs or platform detection. Used by run-tests and mtp-hot-reload; never invoke directly.
Resumen
Test Filter Syntax Reference
Filter syntax depends on the platform and test framework.
VSTest filters (MSTest, xUnit v2, NUnit on VSTest)
dotnet test --filter <EXPRESSION>Expression syntax: <Property><Operator><Value>[|&<Expression>]
Operators:
| Operator | Meaning |
|---|---|
= | Exact match |
!= | Not exact match |
~ | Contains |
!~ | Does not contain |
Combinators: | (OR), & (AND). Parentheses for grouping: (A|B)&C
Supported properties by framework:
| Framework | Properties |
|---|---|
| MSTest | FullyQualifiedName, Name, ClassName, Priority, TestCategory |
| xUnit | FullyQualifiedName, DisplayName, Traits |
| NUnit | FullyQualifiedName, Name, Priority, TestCategory |
An expression without an operator is treated as FullyQualifiedName~<value>.
Examples (VSTest):
# Run tests whose name contains "LoginTest"
dotnet test --filter "Name~LoginTest"
# Run a specific test class
dotnet test --filter "ClassName=MyNamespace.MyTestClass"
# Run tests in a category
dotnet test --filter "TestCategory=Integration"
# Exclude a category
dotnet test --filter "TestCategory!=Slow"
# Combine: class AND category
dotnet test --filter "ClassName=MyNamespace.MyTestClass&TestCategory=Unit"
# Either of two classes
dotnet test --filter "ClassName=MyNamespace.ClassA|ClassName=MyNamespace.ClassB"MTP filters — MSTest and NUnit
MSTest and NUnit on MTP use the same --filter syntax as VSTest (same properties, operators, and combinators). The only difference is how the flag is passed:
# .NET SDK 8/9 (after --)
dotnet test -- --filter "Name~LoginTest"
# .NET SDK 10+ (direct)
dotnet test --filter "Name~LoginTest"MTP filters — xUnit (v3)
xUnit v3 on MTP uses framework-specific filter flags instead of the generic --filter expression:
| Flag | Description |
|---|---|
--filter-class "name" | Run all tests in a given class |
--filter-not-class "name" | Exclude all tests in a given class |
--filter-method "name" | Run a specific test method |
--filter-not-method "name" | Exclude a specific test method |
--filter-namespace "name" | Run all tests in a namespace |
--filter-not-namespace "name" | Exclude all tests in a namespace |
--filter-trait "name=value" | Run tests with a matching trait |
--filter-not-trait "name=value" | Exclude tests with a matching trait |
Multiple values can be specified with a single flag: --filter-class Foo Bar.
# .NET SDK 8/9
dotnet test -- --filter-class "MyNamespace.LoginTests"
# .NET SDK 10+
dotnet test --filter-class "MyNamespace.LoginTests"
# Combine: namespace + trait
dotnet test --filter-namespace "MyApp.Tests.Integration" --filter-trait "Category=Smoke"xUnit v3 query filter language
For complex expressions, use --filter-query with a path-segment syntax:
/<assemblyFilter>/<namespaceFilter>/<classFilter>/<methodFilter>[traitName=traitValue]Each segment matches against: assembly name, namespace, class name, method name. Use * for "match all" in any segment. Documentation: https://xunit.net/docs/query-filter-language
# xUnit.net v3 MTP — using query language (assembly/namespace/class/method[trait])
dotnet test -- --filter-query "/*/*/*IntegrationTests*/*[Category=Smoke]"MTP filters — TUnit
TUnit uses --treenode-filter with a path-based syntax:
--treenode-filter "/<Assembly>/<Namespace>/<ClassName>/<TestName>"Wildcards (*) are supported in any segment. Filter operators can be appended to test names for property-based filtering.
| Operator | Meaning |
|---|---|
* | Wildcard match |
= | Exact property match (e.g., [Category=Unit]) |
!= | Exclude property value |
& | AND (combine conditions) |
| | OR (within a segment, requires parentheses) |
Examples (TUnit):
# All tests in a class
dotnet run --treenode-filter "/*/*/LoginTests/*"
# A specific test
dotnet run --treenode-filter "/*/*/*/AcceptCookiesTest"
# By namespace prefix (wildcard)
dotnet run --treenode-filter "/*/MyProject.Tests.Api*/*/*"
# By custom property
dotnet run --treenode-filter "/*/*/*/*[Category=Smoke]"
# Exclude by property
dotnet run --treenode-filter "/*/*/*/*[Category!=Slow]"
# OR across classes
dotnet run --treenode-filter "/*/*/(LoginTests)|(SignupTests)/*"
# Combined: namespace + property
dotnet run --treenode-filter "/*/MyProject.Tests.Integration/*/*/*[Priority=Critical]"VSTest → MTP filter translation (for migration)
MSTest, NUnit, and xUnit.net v2 (with YTest.MTP.XUnit2): The VSTest --filter syntax is identical on both VSTest and MTP. No changes needed.
xUnit.net v3 (native MTP): xUnit.net v3 does NOT support the VSTest --filter syntax on MTP. Translate filters using xUnit.net v3's native options:
VSTest --filter syntax | xUnit.net v3 MTP equivalent | Notes |
|---|---|---|
FullyQualifiedName~ClassName | --filter-class *ClassName* | Wildcards required for substring match |
FullyQualifiedName=Ns.Class.Method | --filter-method Ns.Class.Method | Exact match on fully qualified method |
Name=MethodName | --filter-method *MethodName* | Wildcards for substring match |
Category=Value (trait) | --filter-trait "Category=Value" | Filter by trait name/value pair |
| Complex expressions | --filter-query "expr" | Uses xUnit.net query filter language (see above) |
Archivos 1 archivo
Instálala a mano
Deska ejecuta esto por ti, para cada agente que elijas. Para ejecutarlo tú en una terminal:
npx skills add dotnet/skills --skill filter-syntaxMás de dotnet
- msbuild-antipatternsdotnetDO NOT INVOKE when the primary request explicitly asks to convert, migrate, modernize, or rewrite a legacy/old-style project to SDK style; use msbuild-modernization. Migration prompts often mention ToolsVersion, explicit Compile/Reference entries, packages.config, or Microsoft.CSharp.targets, but merely reviewing or auditing a file that contains those patterns remains in scope here. USE FOR broad review, audit, lint, or maintainability/correctness checks of project/build files, including custom targets; prioritized cross-cutting findings; discrete anti-patterns; F# ordering/FS0039; cross-platform paths; and focused Import safety verdicts. Review/audit is analysis-only unless fixes are requested. For concrete property/item defects use property-patterns/item-management; use target-authoring for implementation and extension-points for NuGet auto-import/layout discovery. Exclude non-MSBuild systems.3,000 instalaciones en skills.sh0
- directory-build-organizationdotnetUSE ONLY for (1) two or more projects with repeated MSBuild policy, targets, or package versions, or (2) an existing Directory.Build.props/targets/rsp hierarchy with an import, placement, or layering defect. A one-project repo without an existing Directory.Build file is outside scope; do not load this skill. Covers centralizing shared policy and targets, Directory.Packages.props across projects, parent hierarchy/import structure, props-versus-targets placement, and folder/project exceptions. An existing hierarchy defect remains in scope when only one project is affected. For property value or condition semantics use property-patterns. Exclude legacy-to-SDK migration and non-MSBuild systems.2,900 instalaciones en skills.sh0
- msbuild-modernizationdotnetGuide for modernizing and migrating MSBuild project files to SDK-style format. USE FOR: converting legacy .csproj/.vbproj with verbose XML to SDK-style, migrating packages.config to PackageReference, removing Properties/AssemblyInfo.cs in favor of auto-generation, eliminating explicit Compile Include lists via implicit globbing, consolidating shared settings into Directory.Build.props. Indicators of legacy projects: ToolsVersion attribute, an Import of Microsoft.CSharp.targets via $(MSBuildToolsPath), .csproj files over 50 lines for simple projects. DO NOT USE FOR: projects already in SDK-style format, non-.NET build systems (npm, Maven, CMake), .NET Framework projects that cannot move to SDK-style.2,900 instalaciones en skills.sh0
- binlog-failure-analysisdotnetAnalyze MSBuild binary logs to diagnose build failures. USE FOR: build errors that are unclear from console output, diagnosing cascading failures across multi-project builds, tracing MSBuild target execution order, and generally any MSBuild build issues. Requires an existing .binlog file. DO NOT USE FOR: generating binlogs (use binlog-generation), non-MSBuild build systems.2,700 instalaciones en skills.sh0
- binlog-generationdotnetGenerate MSBuild binary logs (binlogs) for build diagnostics and analysis. USE FOR: adding /bl:{} to any dotnet build, test, pack, publish, or restore command to capture a full build execution trace, prerequisite for binlog-failure-analysis and build-perf-diagnostics skills, enabling post-build investigation of errors or performance. Requires MSBuild 17.8+ / .NET 8 SDK+ for {} placeholder; PowerShell must quote the complete switch as '-bl:{}'. DO NOT USE FOR: non-MSBuild build systems (npm, Maven, CMake), analyzing an existing binlog (use binlog-failure-analysis instead).2,600 instalaciones en skills.sh0