kevintsengtw .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