Get the FREE Ultimate OpenClaw Setup Guide →

Dotnet Test

Scanned
npx machina-cli add skill NikiforovAll/claude-code-rules/dotnet-test --openclaw
Files (1)
SKILL.md
7.7 KB

.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

CommandPurpose
dotnet build -p:WarningLevel=0 /clp:ErrorsOnly --verbosity minimalBuild solution with minimal output
dotnet test path/to/Tests.csproj --no-buildRun 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-testsList available tests without running

Filter Operators

OperatorMeaningExample
=Exact matchClassName=MyTests
!=Not equalName!=SkipThis
~ContainsName~Create
!~Does not containName!~Integration
|ORName~Test1|Name~Test2 (note '|' is an escape for markdown)
&ANDName~User&Category=Unit

xUnit Filter Properties

PropertyDescriptionReliabilityExample
FullyQualifiedNameFull test name with namespace✅ ReliableFullyQualifiedName~MyNamespace.MyClass
DisplayNameTest display name (includes Theory parameters)✅ ReliableDisplayName~My_Test_Name or DisplayName~paramValue
NameMethod name⚠️ UnreliableUse FullyQualifiedName~ instead
ClassNameClass name⚠️ UnreliableUse FullyQualifiedName~ instead
CategoryTrait category✅ ReliableCategory=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:

LevelFlagDescription
quiet-v qMinimal output (pass/fail only)
minimal-v mClean summary, no test output
normal-v nDefault, shows discovered tests
detailed-v dShows more details
diagnostic-v diagMost 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:

PropertyxUnitMSTestNUnit
Method nameNameNameName
Class nameClassNameClassNameClassName
Category/TraitCategoryTestCategoryCategory
Priority-PriorityPriority

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

  1. Step 1: Build the solution with minimal output to catch compile errors early
  2. Step 2: Run tests for the specific project using --no-build to skip redundant compilation
  3. 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"

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers