Source profileQuality 66/100

github/awesome-copilot/skills/csharp-xunit/SKILL.md

csharp-xunit

Get best practices for XUnit unit testing, including data-driven tests

Source repository stars
37,126
Declared platforms
0
Static risk flags
0
Last source update
2026-07-28
Source checked
2026-07-28

Decision brief

What it does—and where it fits

Your goal is to help me write effective unit tests with XUnit, covering both standard and data-driven testing approaches.

Best for

    Not for

    • Tasks that require unconfirmed production actions or broad system permissions.
    • Environments where the pinned source and install steps cannot be inspected.

    Compatibility matrix

    Platform support, with evidence labels

    PlatformStatusEvidenceWhat to check
    CodexNot declaredNo explicit evidencePortability before use
    Claude CodeNot declaredNo explicit evidencePortability before use
    CursorNot declaredNo explicit evidencePortability before use
    Gemini CLINot declaredNo explicit evidencePortability before use
    Open the compatibility checker

    Installation

    Inspect first. Install second.

    The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

    Source-detected install commandSource
    npx skills add https://github.com/github/awesome-copilot --skill "skills/csharp-xunit"
    Safe inspection promptEditorial

    Inspect the Agent Skill "csharp-xunit" from https://github.com/github/awesome-copilot/blob/9933dcad5be5caeb288cebcd370eeeb2fc2f1685/skills/csharp-xunit/SKILL.md at commit 9933dcad5be5caeb288cebcd370eeeb2fc2f1685. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

    Workflow

    What the source asks the agent to do

    1. 01

      Project Setup

      Use a separate test project with naming convention [ProjectName].Tests

      Use a separate test project with naming convention [ProjectName].TestsReference Microsoft.NET.Test.Sdk, xunit, and xunit.runner.visualstudio packagesCreate test classes that match the classes being tested (e.g., CalculatorTests for Calculator)
    2. 02

      Test Structure

      No test class attributes required (unlike MSTest/NUnit)

      No test class attributes required (unlike MSTest/NUnit)Use fact-based tests with [Fact] attribute for simple testsFollow the Arrange-Act-Assert (AAA) pattern
    3. 03

      Standard Tests

      Keep tests focused on a single behavior

      Keep tests focused on a single behaviorAvoid testing multiple behaviors in one test methodUse clear assertions that express intent
    4. 04

      Data-Driven Tests

      Use [Theory] combined with data source attributes

      Use [Theory] combined with data source attributesUse [InlineData] for inline test dataUse [MemberData] for method-based test data

    Permission review

    Static risk signals and limitations

    No configured static risk pattern was detected

    This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.

    Evidence record

    Why each signal appears

    EvidenceSourceComputedTestedEditorial
    SignalValueEvidence typeMeaning
    Quality score66/100ComputedDocumentation, specificity, maintenance, and trust rules
    Repository stars37,126SourceRepository attention, not individual Skill quality
    Compatibility0 platformsSourceDeclared in the catalog source record
    Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

    Pinned source

    Provenance and original SKILL.md

    Repository
    github/awesome-copilot
    Skill path
    skills/csharp-xunit/SKILL.md
    Commit
    9933dcad5be5caeb288cebcd370eeeb2fc2f1685
    License
    MIT
    Collected
    2026-07-28
    Default branch
    main
    View the original SKILL.md

    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

    Alternatives

    Compare before choosing