Csharp Xunit
Author maintainable XUnit tests in a .NET test project using Facts, Theories, fixtures, and dotnet test workflows.
Overview
C# XUnit is an agent skill for the Ship phase that teaches XUnit unit test structure, data-driven tests, and dotnet test practices for .NET projects.
Install
npx skills add https://github.com/github/awesome-copilot --skill csharp-xunitWhat is this skill?
- Separate [ProjectName].Tests project with Microsoft.NET.Test.Sdk and xunit packages
- Arrange-Act-Assert with MethodName_Scenario_ExpectedBehavior naming
- [Fact] for single-case tests; [Theory] with InlineData/MemberData for data-driven cases
- IClassFixture and ICollectionFixture for shared setup without test interdependencies
- dotnet test as the standard run loop for CI and local verification
Adoption & trust: 9.1k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your .NET code lacks consistent test projects, naming, or Theory usage and reviews keep flagging flaky or overloaded test methods.
Who is it for?
Solo builders adding or refactoring unit tests in C# APIs, libraries, or small backend services.
Skip if: Integration or UI test suites (Playwright/Selenium), non-.NET stacks, or teams standardized on NUnit/MSTest who will not switch.
When should I use this skill?
User asks for XUnit best practices, C# unit testing help, data-driven tests, or dotnet test project setup.
What do I get? / Deliverables
You get a standard Tests project, focused Facts and Theories, and repeatable dotnet test runs suitable for CI.
- Test class structure matching production types
- Fact and Theory test methods
- Fixture-based shared setup patterns
Recommended Skills
Journey fit
Unit testing guidance belongs on the Ship shelf as the gate before confident releases, even when tests are written during Build. Testing subphase is the canonical home for xUnit structure, naming, and data-driven patterns—not API design or deployment.
How it compares
Opinionated XUnit unit-test playbook—not a test generator MCP or full integration-testing skill.
Common Questions / FAQ
Who is csharp-xunit for?
Solo and indie .NET developers who want clear unit tests with xunit, dotnet test, and data-driven Theories without MSTest/NUnit baggage.
When should I use csharp-xunit?
Use it in Ship when writing or reviewing unit tests, setting up a .Tests project, or converting ad-hoc tests to Facts and Theories before merge or release.
Is csharp-xunit safe to install?
It is documentation-style guidance with no inherent network access; still review the Security Audits panel on this Prism page before enabling any skill in your agent.
SKILL.md
READMESKILL.md - Csharp Xunit
# 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<T>` for shared context between tests in a class - Use `ICollectionFixture<T>` 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<T>` or `await Assert.ThrowsAsync<T>` 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