filter-syntax
Reference data for test filter syntax across all platform and framework combinations: VSTest --filter expressions, MTP filters for MSTest/NUnit/xUnit v3/TUnit, and VSTest-to-MTP filter translation. DO NOT USE directly — loaded by run-tests, mtp-hot-reload, and migrate-vstest-to-mtp when they need filter syntax.
What this skill does
# 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) |
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.