Csharp Nunit
Apply NUnit conventions—fixtures, AAA, and data-driven TestCase patterns—when adding or refactoring C# unit tests in a dedicated test project.
Overview
csharp-nunit is an agent skill most often used in Ship (also Build backend) that teaches NUnit unit testing patterns including data-driven tests for C# projects.
Install
npx skills add https://github.com/github/awesome-copilot --skill csharp-nunitWhat is this skill?
- Separate [ProjectName].Tests project with Microsoft.NET.Test.Sdk, NUnit, and NUnit3TestAdapter
- AAA pattern and MethodName_Scenario_ExpectedBehavior naming
- Lifecycle attributes: SetUp, TearDown, OneTimeSetUp, OneTimeTearDown, SetUpFixture
- Data-driven coverage via TestCase, TestCaseSource, and Values
- Covers standard tests plus data-driven patterns: TestCase, TestCaseSource, and Values
- Documents six lifecycle hook attribute types for setup and teardown
Adoption & trust: 8.6k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent writes flaky or bloated C# tests without proper NUnit structure, fixtures, or data-driven cases.
Who is it for?
Indie .NET developers who want agent-generated unit tests to match team-standard NUnit layout and naming.
Skip if: xUnit or MSTest-only codebases, full integration or E2E test suites, or non-C# stacks.
When should I use this skill?
Writing or reviewing C# unit tests with NUnit, including data-driven cases and dotnet test project setup.
What do I get? / Deliverables
New and refactored tests follow NUnit conventions and run cleanly via dotnet test in a dedicated test project.
- NUnit test classes following naming and AAA conventions
- Data-driven test methods using TestCase or TestCaseSource where appropriate
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship testing where quality gates run before release, even though test authoring often starts during Build. Unit test structure and dotnet test execution are core testing subphase work for .NET codebases.
Where it fits
Add CalculatorTests alongside a new service method using TestCase tables for edge inputs.
Harden release candidates with idempotent NUnit suites and OneTimeSetUp for expensive shared fixtures.
Refactor regression tests after a bug fix so each test asserts one behavior with clear AAA sections.
How it compares
Opinionated NUnit procedural guide—not a test runner MCP or snapshot golden-master framework.
Common Questions / FAQ
Who is csharp-nunit for?
Solo builders and small teams on C# who standardize on NUnit and want coding agents to follow the same fixture and data-driven patterns they would in a code review.
When should I use csharp-nunit?
In Ship testing before release, during Build backend when adding tests alongside features, or when refactoring legacy tests to AAA and TestCase-driven coverage.
Is csharp-nunit safe to install?
It provides testing guidance only; review the Security Audits panel on this Prism page before installing any skill into your agent.
SKILL.md
READMESKILL.md - Csharp Nunit
# NUnit Best Practices Your goal is to help me write effective unit tests with NUnit, 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, NUnit, and NUnit3TestAdapter 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 - Apply `[TestFixture]` attribute to test classes - Use `[Test]` attribute for test methods - Follow the Arrange-Act-Assert (AAA) pattern - Name tests using the pattern `MethodName_Scenario_ExpectedBehavior` - Use `[SetUp]` and `[TearDown]` for per-test setup and teardown - Use `[OneTimeSetUp]` and `[OneTimeTearDown]` for per-class setup and teardown - Use `[SetUpFixture]` for assembly-level setup and teardown ## 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 `[TestCase]` for inline test data - Use `[TestCaseSource]` for programmatically generated test data - Use `[Values]` for simple parameter combinations - Use `[ValueSource]` for property or method-based data sources - Use `[Random]` for random numeric test values - Use `[Range]` for sequential numeric test values - Use `[Combinatorial]` or `[Pairwise]` for combining multiple parameters ## Assertions - Use `Assert.That` with constraint model (preferred NUnit style) - Use constraints like `Is.EqualTo`, `Is.SameAs`, `Contains.Item` - Use `Assert.AreEqual` for simple value equality (classic style) - Use `CollectionAssert` for collection comparisons - Use `StringAssert` for string-specific assertions - Use `Assert.Throws<T>` or `Assert.ThrowsAsync<T>` to test exceptions - Use descriptive messages in assertions for clarity on failure ## Mocking and Isolation - Consider using Moq or NSubstitute alongside NUnit - 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 categories with `[Category("CategoryName")]` - Use `[Order]` to control test execution order when necessary - Use `[Author("DeveloperName")]` to indicate ownership - Use `[Description]` to provide additional test information - Consider `[Explicit]` for tests that shouldn't run automatically - Use `[Ignore("Reason")]` to temporarily skip tests