csharp-nunit

SKILL.md

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