PluginBench
Skill
Official
Review
Audit score 70

csharp-xunit

github/awesome-copilot

XUnit best practices for C# unit testing, including data-driven tests and test organization.

What is csharp-xunit?

XUnit is a modern unit testing framework for .NET. Use this skill to write effective unit tests following XUnit conventions, including standard fact-based tests, data-driven theory tests, and proper test isolation with fixtures.

  • Write fact-based and theory-based (data-driven) tests with XUnit attributes
  • Organize tests using Arrange-Act-Assert pattern and naming conventions
  • Share test context across tests using IClassFixture and ICollectionFixture
  • Create data-driven tests with InlineData, MemberData, and ClassData attributes
  • Assert on values, references, collections, exceptions, and regex patterns
  • Categorize and skip tests using traits and conditional attributes

How to install csharp-xunit

npx skills add https://github.com/github/awesome-copilot --skill csharp-xunit
Prerequisites
  • Create a separate test project named [ProjectName].Tests
  • Install NuGet packages: Microsoft.NET.Test.Sdk, xunit, xunit.runner.visualstudio
  • Use .NET SDK with dotnet test command available
Claude Code
Cursor
Windsurf
Cline

How to use csharp-xunit

  1. 1.Create test classes matching the classes being tested (e.g., CalculatorTests)
  2. 2.Use [Fact] for simple single-scenario tests or [Theory] with data attributes for multiple scenarios
  3. 3.Follow the Arrange-Act-Assert pattern within each test method
  4. 4.Name tests as MethodName_Scenario_ExpectedBehavior
  5. 5.Use appropriate assertions (Assert.Equal, Assert.Throws, Assert.Contains, etc.)
  6. 6.For shared setup, use constructor for initialization and IDisposable.Dispose() for cleanup
  7. 7.Run tests with dotnet test command

Use cases

Good for
  • Unit testing business logic in a Calculator or utility class with multiple scenarios
  • Testing the same method with different input values using Theory and InlineData
  • Sharing database connections or mock objects across multiple test classes with fixtures
  • Validating exception handling with Assert.Throws or Assert.ThrowsAsync
  • Organizing large test suites by feature using traits and collection fixtures
Who it's for
  • C# developers writing unit tests
  • Teams adopting XUnit as their testing framework
  • Developers migrating from MSTest or NUnit to XUnit

csharp-xunit FAQ

What's the difference between [Fact] and [Theory]?

[Fact] is for a single test case with no parameters. [Theory] is for data-driven tests that run multiple times with different input data from InlineData, MemberData, or ClassData attributes.

How do I share setup code between tests?

Use the constructor for setup code that runs before each test. For shared context across multiple tests, use IClassFixture<T> for a single class or ICollectionFixture<T> for multiple classes. Implement IDisposable.Dispose() for teardown.

How do I test that an exception is thrown?

Use Assert.Throws<ExceptionType>(() => methodCall()) for synchronous code or await Assert.ThrowsAsync<ExceptionType>(() => asyncMethodCall()) for async code.

Can I use mocking with XUnit?

Yes. XUnit works well with mocking libraries like Moq or NSubstitute. Mock dependencies to isolate the unit under test, and use interfaces to facilitate mocking.

How do I organize and filter tests?

Use [Trait("Category", "CategoryName")] to categorize tests, then filter by trait when running dotnet test. Use collection fixtures to group related tests with shared dependencies.

Full instructions (SKILL.md)

Source of truth, from github/awesome-copilot.


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<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