dotnet-testing
Write and run .NET tests following TDD principles. Use when writing tests, implementing TDD workflow, verifying test coverage, or debugging test failures.
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
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/dotnet-testing/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How dotnet-testing Compares
| Feature / Agent | dotnet-testing | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/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
Perform dynamic security testing against running web applications and APIs to discover vulnerabilities through active probing and fuzzing.
dotnet-windbg-debugging
Debugs Windows apps via WinDbg MCP. Crash, hang, high-CPU, and memory triage from dumps or live attach.
dotnet-webapi
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
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
.NET MAUI component and application patterns Triggers on: **/*.xaml, **/*.cs
dotnet-framework
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
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
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
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
Orchestrates .NET Aspire apps. AppHost, service discovery, components, dashboard, health checks.
dotnet-advisor
Routes .NET/C# work to domain skills. Loads coding-standards for code paths.
copilot-sdk-dotnet
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.