Intro in this page language first. The official description stays in its original wording; we do not rewrite SKILL.md.
What it does
Get best practices for XUnit unit testing, including data-driven tests
When to use it
The official description does not include a separate “Use when”. Per the spec, agents activate this skill when the task matches keywords in that description.
How agents load it
Per Agent Skills progressive disclosure: name and description load at startup (~100 tokens); the full SKILL.md body loads when the skill activates; scripts/, references/, and assets/ load only as needed. This file's sections: XUnit Best Practices; Project Setup; Test Structure; Standard Tests; Data-Driven Tests; Assertions.
File analysis
File analysis: instruction-only skill (SKILL.md). The agent loads the full body when activated.
XUnit Best PracticesProject SetupTest StructureStandard TestsData-Driven TestsAssertionsMocking and IsolationTest Organization
Choose the target agent and installation scope, keep referenced package files, then verify the skill appears in the client's catalog.
Ask your Agent to install
Copy these instructions to a compatible agent and confirm the target directory matches your client.
Install the agent skill "csharp-xunit" into my project. The full SKILL.md and official description are at https://zicq.com/en/skills/skl-7d8b4df7ddb0edb1-Csharp-Xunit.html
Save it as .cursor/skills/csharp-xunit/SKILL.md or .claude/skills/csharp-xunit/SKILL.md and keep the frontmatter name and description exactly as-is.
The CLI lets you choose the agent interactively. The default scope is the project; use -g for user scope. Confirm package availability with the discovery command, then use npx skills list to inspect installed skills.
Readable layout
---
name: csharp-xunit
description: 'Get best practices for XUnit unit testing, including data-driven tests'
---
# XUnit Best Practices
Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.
## Project Setup
- Use a separate test project with naming convention `[ProjectName].Tests`
- Reference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packages
- Create test classes that match the classes being tested (e.g., `CalculatorTests` for `Calculator`)
- Use .NET SDK test commands: `dotnet test` for running tests
## Test Structure
- No test class attributes required (unlike MSTest/NUnit)
- Use fact-based tests with `[Fact]` attribute for simple tests
- Follow the Arrange-Act-Assert (AAA) pattern
- Name tests using the pattern `MethodName_Scenario_ExpectedBehavior`
- Use constructor for setup and `IDisposable.Dispose()` for teardown
- Use `IClassFixture` for shared context between tests in a class
- Use `ICollectionFixture` for shared context between multiple test classes
## Standard Tests
- Keep tests focused on a single behavior
- Avoid testing multiple behaviors in one test method
- Use clear assertions that express intent
- Include only the assertions needed to verify the test case
- Make tests independent and idempotent (can run in any order)
- Avoid test interdependencies
## Data-Driven Tests
- Use `[Theory]` combined with data source attributes
- Use `[InlineData]` for inline test data
- Use `[MemberData]` for method-based test data
- Use `[ClassData]` for class-based test data
- Create custom data attributes by implementing `DataAttribute`
- Use meaningful parameter names in data-driven tests
## Assertions
- Use `Assert.Equal` for value equality
- Use `Assert.Same` for reference equality
- Use `Assert.True`/`Assert.False` for boolean conditions
- Use `Assert.Contains`/`Assert.DoesNotContain` for collections
- Use `Assert.Matches`/`Assert.DoesNotMatch` for regex pattern matching
- Use `Assert.Throws` or `await Assert.ThrowsAsync` to test exceptions
- Use fluent assertions library for more readable assertions
## Mocking and Isolation
- Consider using Moq or NSubstitute alongside XUnit
- Mock dependencies to isolate units under test
- Use interfaces to facilitate mocking
- Consider using a DI container for complex test setups
## Test Organization
- Group tests by feature or component
- Use `[Trait("Category", "CategoryName")]` for categorization
- Use collection fixtures to group tests with shared dependencies
- Consider output helpers (`ITestOutputHelper`) for test diagnostics
- Skip tests conditionally with `Skip = "reason"` in fact/theory attributes