TestsSûr100100/100
Filter Syntax (.NET)
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.
ou envoie-le directement à ton agent.
Installer dans ton projet
$ curl -fsSL https://arboristhree.xyz/cli/install-skill.mjs -o /tmp/arboris-install-skill.mjs && node /tmp/arboris-install-skill.mjs filter-syntax__dotnet-skills__plugins-dotnet-test-skills-765e1edc08af.NET
dotnet/skills
Contenu à copier
--- name: filter-syntax description: "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." user-invocable: false disable-model-invocation: true license: MIT metadata: origin: .NET --- # Test Filter Syntax Reference Filter syntax depends on the **platform** and **test framework**. ## VSTest filters (MSTest, xUnit v2, NUnit on VSTest) ```bash 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):** ```bash # 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: ```bash # .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`. ```bash # .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: ```text /<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> ```shell # 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: ```text --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):** ```bash # 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) |
Colle ce Markdown dans ton agent ou utilise les boutons ci-dessus pour l’écrire dans ton projet.
Ce que fait Filter Syntax (.NET)
Applique les pratiques du skill filter-syntax__dotnet-skills__plugins-dotnet-test-skills-765e1edc08af.
Comment utiliser Filter Syntax (.NET)
1
Copie le prompt
Un clic copie le prompt packagé (ou l'envoie à ton agent).
2
L'agent installe le skill
Il ajoute le SKILL.md et ses ressources à ton projet.
3
Activation automatique
Le skill s'active dès que le contexte correspond.
Déclencheurs pour Filter Syntax (.NET)
Dis simplement à ton agent quelque chose comme :
Applique le skill filter-syntax__dotnet-skills__plugins-dotnet-test-skills-765e1edc08af à cette tâche
Utilise filter-syntax__dotnet-skills__plugins-dotnet-test-skills-765e1edc08af pour améliorer cette implémentation
Passe en revue ce sujet avec filter-syntax__dotnet-skills__plugins-dotnet-test-skills-765e1edc08af
Skills liés à Filter Syntax (.NET)
Add New Op (Alibaba)
为 MNN 框架新增算子。包含 Schema 定义、形状计算、几何计算、后端实现、单元测试的完整 TDD 流程。分 5 步执行,每步有独立测试标准。ai-regression-testing
Regression testing strategies for AI-assisted development. Sandbox-mode API testing without database dependencies, automated bug-check workflows, and patterns to catch AI blind spots where the same model writes and reviews code. Use when adding regression coverage to AI-assisted code, or when the same model both wrote and reviewed a change.Analyze Test Report (PyTorch)
Analyze torch-tensorrt local test results and drive failures to a fix. Use when the user pastes a test report / summary, asks why tests failed, asks to triage or fix failing tests, or mentions the JUnit/test-summary output from `just tests-report` / `just test-summary`. Covers where the JUnit XMLs live, how to read the consolidated report, how to reproduce a single failure, and how to categorize (real bug vs torch-API change vs OOM/skip vs flake).