qa-testing-nunit

# C# Testing NUnit Fixtures ## Quick Reference - Classify test scope first: API, component, or integration. - Lock runtime constraints before execution: Docker availability, framework target, and explicitly excluded suites. - Use this skill for test-suite architecture and fixture behavior, not for general service implementation or CI graph refactors. - Default to two files per handler/use case: `<Feature>Fixture.cs` and `<Feature>Tests.cs`. - For full-cycle API tests, use controller-focused structure: one fixture per controller/test family and one base `ApiTest.cs` + `ApiFixture.cs` (split by scenario family only when needed). - Do not translate SpecFlow/Taffy step definitions into C# line-by-line; rewrite scenario intent into idiomatic API tests. - For API migrations, avoid one global shared setup fixture; each controller/test family fixture owns its own dependencies. - Fixture ownership for API tests should include DB launcher + migrators + WireMock + WebApplicationFactory + client. - Reset mutable state in `[SetUp]`; dispose all owned infra in `[OneTimeTearDown]`. - For DB bootstrapping, follow pricing-style `DatabaseLauncher + MigratorContainer` from `tests/utils/Sc.Fin.Pricing.Tests.Utils/Testcontainers`. - Use canonical migrator command `dotnet Sc.Tool.FluentMigrator.dll migrateup -m /sql` and avoid custom ready-check arguments in tests. - Keep migrator ordering explicit (dependency migrators first, domain migrator last) and support fixture-level optional migrator togg...