Dotnet Test
Scannednpx machina-cli add skill NikiforovAll/claude-code-rules/dotnet-test --openclaw.NET Test Runner
Run .NET tests selectively using a build-first, test-targeted workflow optimized for development speed.
Core Workflow
Follow this workflow to run tests efficiently:
Step 1: Build Solution First
Build the entire solution with minimal output to catch compile errors early:
dotnet build -p:WarningLevel=0 /clp:ErrorsOnly --verbosity minimal
Step 2: Run Specific Project Tests
Run tests for the specific test project with --no-build to skip redundant compilation:
dotnet test path/to/project --no-build --verbosity minimal
Step 3: Filter When Targeting Specific Tests
Narrow down to specific tests using filter expressions:
# By method name using FullyQualifiedName (recommended)
dotnet test --no-build --filter "FullyQualifiedName~MyTestMethod"
# By class name using FullyQualifiedName (recommended)
dotnet test --no-build --filter "FullyQualifiedName~MyTestClass"
# By parameter values in Theory tests (xUnit)
dotnet test --no-build --filter "DisplayName~paramValue"
# Combined filters
dotnet test --no-build --filter "FullyQualifiedName~Create|FullyQualifiedName~Update"
Note: Properties Name~ and ClassName= may not work reliably. Use FullyQualifiedName~ instead.
Quick Reference
Commands
| Command | Purpose |
|---|---|
dotnet build -p:WarningLevel=0 /clp:ErrorsOnly --verbosity minimal | Build solution with minimal output |
dotnet test path/to/Tests.csproj --no-build | Run project tests (skip build) |
dotnet test --no-build --logger "console;verbosity=detailed" | Show ITestOutputHelper output |
dotnet test --no-build --filter "..." | Run filtered tests |
dotnet test --no-build --list-tests | List available tests without running |
Filter Operators
| Operator | Meaning | Example |
|---|---|---|
= | Exact match | ClassName=MyTests |
!= | Not equal | Name!=SkipThis |
~ | Contains | Name~Create |
!~ | Does not contain | Name!~Integration |
| | OR | Name~Test1|Name~Test2 (note '|' is an escape for markdown) |
& | AND | Name~User&Category=Unit |
xUnit Filter Properties
| Property | Description | Reliability | Example |
|---|---|---|---|
FullyQualifiedName | Full test name with namespace | ✅ Reliable | FullyQualifiedName~MyNamespace.MyClass |
DisplayName | Test display name (includes Theory parameters) | ✅ Reliable | DisplayName~My_Test_Name or DisplayName~paramValue |
Name | Method name | ⚠️ Unreliable | Use FullyQualifiedName~ instead |
ClassName | Class name | ⚠️ Unreliable | Use FullyQualifiedName~ instead |
Category | Trait category | ✅ Reliable | Category=Unit |
When to use DisplayName: Essential for filtering Theory tests by their parameter values. xUnit includes all parameter values in the DisplayName (e.g., MyTest(username: "admin", age: 30)), making it ideal for running specific test cases. See references/theory-parameter-filtering.md for detailed guidance.
Common Filter Patterns
# Run tests containing "Create" in method name
dotnet test --no-build --filter "FullyQualifiedName~Create"
# Run tests in a specific class
dotnet test --no-build --filter "FullyQualifiedName~UserServiceTests"
# Run tests matching namespace pattern
dotnet test --no-build --filter "FullyQualifiedName~MyApp.Tests.Unit"
# Run Theory tests with specific parameter value
dotnet test --no-build --filter "DisplayName~admin_user"
# Run tests with specific trait
dotnet test --no-build --filter "Category=Integration"
# Exclude slow tests
dotnet test --no-build --filter "Category!=Slow"
# Combined: class AND parameter value (Theory tests)
dotnet test --no-build --filter "FullyQualifiedName~OrderTests&DisplayName~USD"
# Multiple parameter values (OR condition)
dotnet test --no-build --filter "DisplayName~EUR|DisplayName~GBP"
ITestOutputHelper Output
To see output from xUnit's ITestOutputHelper, use the console logger with detailed verbosity:
dotnet test --no-build --logger "console;verbosity=detailed"
Reducing Output Noise
Verbosity levels for dotnet test:
| Level | Flag | Description |
|---|---|---|
| quiet | -v q | Minimal output (pass/fail only) |
| minimal | -v m | Clean summary, no test output |
| normal | -v n | Default, shows discovered tests |
| detailed | -v d | Shows more details |
| diagnostic | -v diag | Most verbose |
To see test output, use grep to filter out discovery messages (for xUnit):
dotnet test --no-build --logger "console;verbosity=detailed" 2>&1 | grep -v "Discovered \[execution\]"
Framework Differences
This skill focuses on xUnit. For MSTest or NUnit, filter property names differ:
| Property | xUnit | MSTest | NUnit |
|---|---|---|---|
| Method name | Name | Name | Name |
| Class name | ClassName | ClassName | ClassName |
| Category/Trait | Category | TestCategory | Category |
| Priority | - | Priority | Priority |
Progressive Disclosure
For advanced scenarios, load additional references:
- references/theory-parameter-filtering.md - Filtering xUnit Theory tests by parameter values (string, numeric, boolean, etc.)
- references/blame-mode.md - Debugging test crashes and hangs with
--blame - references/parallel-execution.md - Controlling parallel test execution
Load these references when:
- Working with xUnit Theory tests and need to filter by specific parameter values
- Tests are crashing or hanging unexpectedly
- Diagnosing test isolation issues
- Optimizing test run performance
When to Use This Skill
Invoke when the user needs to:
- Run targeted tests during development
- Filter tests by method or class name
- Filter xUnit Theory tests by specific parameter values (e.g., run only admin user test cases)
- Understand test output and filtering options
- Debug failing or hanging tests
Source
git clone https://github.com/NikiforovAll/claude-code-rules/blob/main/plugins/handbook-dotnet/skills/dotnet-test/SKILL.mdView on GitHub Overview
The .NET Test skill enables selective execution of unit tests in a build-first workflow. It focuses on xUnit tests, letting you build once and run only the relevant tests to speed up feedback during development.
How This Skill Works
It first builds the entire solution with minimal output to surface compile errors, then runs the target test project with --no-build to skip redundant compilation. You filter results using --filter (for example FullyQualifiedName) to target specific tests or test classes.
When to Use It
- You want fast feedback in a large solution by performing a single build and then testing a subset of projects.
- You need to run tests only for a specific test project instead of the entire test suite.
- You aim to target methods or classes using FullyQualifiedName for precise test selection.
- You work with Theory tests and want to filter by parameter values via DisplayName or FullyQualifiedName.
- You are integrating a CI/CD flow that builds once and subsequently runs targeted tests.
Quick Start
- Step 1: Build the solution with minimal output to catch compile errors early
- Step 2: Run tests for the specific project using --no-build to skip redundant compilation
- Step 3: Narrow results with a filter, e.g. --filter "FullyQualifiedName~MyTestMethod"
Best Practices
- Build the solution with minimal output to keep logs clean and speed up the process.
- Use dotnet test with --no-build when testing a specific project to avoid re-compiling.
- Filter with FullyQualifiedName~ for reliable test targeting; prefer DisplayName only for parametric tests when necessary.
- Set --verbosity minimal for faster feedback; enable detailed logging only when debugging.
- Validate filters with --list-tests if supported, and combine filters with | or & as needed.
Example Use Cases
- dotnet build -p:WarningLevel=0 /clp:ErrorsOnly --verbosity minimal
- dotnet test path/to/Tests.csproj --no-build --verbosity minimal
- dotnet test --no-build --filter "FullyQualifiedName~MyTestMethod"
- dotnet test --no-build --filter "FullyQualifiedName~MyTestClass"
- dotnet test --no-build --filter "FullyQualifiedName~Create|FullyQualifiedName~Update"