dotnet-testing

Write and run .NET tests following TDD principles. Use when writing tests, implementing TDD workflow, verifying test coverage, or debugging test failures.

16 stars

Best use case

dotnet-testing is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Write and run .NET tests following TDD principles. Use when writing tests, implementing TDD workflow, verifying test coverage, or debugging test failures.

Teams using dotnet-testing should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/dotnet-testing/SKILL.md --create-dirs "https://raw.githubusercontent.com/diegosouzapw/awesome-omni-skill/main/skills/development/dotnet-testing/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/dotnet-testing/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How dotnet-testing Compares

Feature / Agentdotnet-testingStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Write and run .NET tests following TDD principles. Use when writing tests, implementing TDD workflow, verifying test coverage, or debugging test failures.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

Related Guides

SKILL.md Source

# .NET Testing Standards

## When to Use This Skill

Use this skill when you need to:

- Write unit tests for new functionality
- Follow TDD (Test-Driven Development) workflow
- Debug failing tests
- Review test quality and coverage

## Prerequisites

**Before writing tests:** Read `.planning/CONVENTIONS.md` for repository-specific test patterns (framework, naming, mocking library). If it doesn't exist, the calling agent should invoke the `Repo Analyser` subagent first.

## Hard Rules

### Must

1. **Write failing test first (TDD)** — Test drives the implementation, not vice versa
2. **One assertion concept per test** — Test one behaviour, multiple asserts on same object is OK
3. **Use repo's existing test framework** — Don't mix xUnit and NUnit in same solution
4. **Tests must be deterministic** — No dependency on time, random, or external state
5. **Follow repo's naming convention** — Check CONVENTIONS.md for pattern
6. **Test behaviour, not implementation** — Tests should survive refactoring

### Must Not

1. **Test private methods directly** — Test through public API; if you need to test private, extract a class
2. **Use Thread.Sleep in tests** — Use async/await, polling with timeout, or test doubles
3. **Share mutable state between tests** — Each test gets fresh state
4. **Mock what you don't own** — Wrap third-party APIs, mock the wrapper
5. **Write tests for trivial code** — Auto-properties, simple DTOs don't need tests
6. **Depend on test execution order** — Tests must run independently and in parallel

## TDD Workflow

1. **RED** — Write a test that expects the behaviour. Run it — it MUST fail. If it passes, the test is wrong or the feature already exists.
2. **GREEN** — Write the MINIMUM code to make the test pass. Hard-coding is acceptable if it satisfies the test.
3. **REFACTOR** — Remove duplication, improve naming, extract methods/classes. Run ALL tests — they MUST still pass.

## Commands Reference

All `dotnet` commands work identically across all shells.

```
dotnet test
dotnet test ./tests/MyProject.UnitTests/
dotnet test --filter "FullyQualifiedName~OrderServiceTests"
dotnet test --filter "Category=Unit"
dotnet test --filter "FullyQualifiedName!~IntegrationTests & FullyQualifiedName!~Integration.Tests"
dotnet test --list-tests
dotnet test --collect:"XPlat Code Coverage"
```

The compound filter excludes all tests from integration test projects — covering both `IntegrationTests` and `Integration.Tests` naming conventions. Use this when integration tests are excluded via the `quality-gates` skill protocol.

## Verification Checklist

Before considering tests complete:

- [ ] Test fails before implementation (TDD RED)
- [ ] Test passes after implementation (TDD GREEN)
- [ ] Refactoring done with tests still passing
- [ ] Follows naming convention from CONVENTIONS.md
- [ ] One behaviour per test
- [ ] No flaky/non-deterministic elements
- [ ] Mocks are for external dependencies only
- [ ] Test class has same structure as others in repo

Related Skills

dynamic-application-security-testing

16
from diegosouzapw/awesome-omni-skill

Perform dynamic security testing against running web applications and APIs to discover vulnerabilities through active probing and fuzzing.

dotnet-windbg-debugging

16
from diegosouzapw/awesome-omni-skill

Debugs Windows apps via WinDbg MCP. Crash, hang, high-CPU, and memory triage from dumps or live attach.

dotnet-webapi

16
from diegosouzapw/awesome-omni-skill

Build ASP.NET Core Web APIs with .NET 10 (C# 14.0). Supports project scaffolding, CRUD operations, Entity Framework integration, dependency injection, testing with xUnit, Docker containerization, and following 2025 best practices. Use when creating REST APIs, microservices, backend services, implementing CRUD operations, setting up Entity Framework, adding authentication/authorization, or containerizing .NET applications. Triggers on .NET, ASP.NET Core, C#, Web API, REST API, microservices, dotnet, csharp development tasks.

dotnet-to-react-python-refactor

16
from diegosouzapw/awesome-omni-skill

Agent skill for refactoring .NET applications into a React frontend + Python backend. Use for migrating/modernizing .NET apps (ASP.NET MVC, Web API, Blazor, Web Forms) to React + Python, or analyzing .NET codebases for migration planning.

dotnet-maui

16
from diegosouzapw/awesome-omni-skill

.NET MAUI component and application patterns Triggers on: **/*.xaml, **/*.cs

dotnet-framework

16
from diegosouzapw/awesome-omni-skill

Guidance for working with .NET Framework projects. Includes project structure, C# language version, NuGet management, and best practices. Triggers on: **/*.csproj, **/*.cs

dotnet-framework-4-8-expert

16
from diegosouzapw/awesome-omni-skill

Expert .NET Framework 4.8 specialist mastering legacy enterprise applications. Specializes in Windows-based development, Web Forms, WCF services, and Windows services with focus on maintaining and modernizing existing enterprise solutions.

dotnet-backend-patterns

16
from diegosouzapw/awesome-omni-skill

Master C#/.NET backend development patterns for building robust APIs, MCP servers, and enterprise applications. Covers async/await, dependency injection, Entity Framework Core, Dapper, configuratio...

dotnet-aspire

16
from diegosouzapw/awesome-omni-skill

Adds .NET Aspire cloud-native orchestration to existing .NET solutions. Analyzes solution structure to identify services (APIs, web apps, workers), creates AppHost and ServiceDefaults projects, configures service discovery, adds NuGet packages, and sets up distributed application orchestration. Use when adding Aspire to .NET solutions or creating new cloud-ready distributed applications.

dotnet-aspire-patterns

16
from diegosouzapw/awesome-omni-skill

Orchestrates .NET Aspire apps. AppHost, service discovery, components, dashboard, health checks.

dotnet-advisor

16
from diegosouzapw/awesome-omni-skill

Routes .NET/C# work to domain skills. Loads coding-standards for code paths.

copilot-sdk-dotnet

16
from diegosouzapw/awesome-omni-skill

Build applications with GitHub Copilot CLI SDKs for .NET. Use for direct CopilotClient integration or Microsoft Agent Framework. Covers sessions, streaming, tools, MCP, permissions, and multi-agent workflows.