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