Testing Strategy — Template

Testing Strategy
Reenactment Society Website
Template — Approach, Coverage Targets & Conventions

📝 This document defines how testing is approached across the project. It sets expectations
for both developers. Review and update each sprint if the approach changes.

1. Testing Principles
Our approach to testing is guided by the following principles:
• Tests are written as part of building a feature, not after. They are part of the Definition
of Done.
• Tests must be trustworthy. A test that gives false confidence is worse than no test.
• Tests should be fast. Slow tests do not get run. Unit tests should run in milliseconds.
• Tests should be independent. No test should rely on the state left by another test.
• Tests are documentation. A well-written test communicates intent as clearly as the
code it tests.

2. Test Types & Scope

Test Type What It Tests Tools
Unit Tests Individual domain entities, xUnit, FluentAssertions, Moq / NSubstitute
value objects, and application
services in isolation. No
database, no HTTP.
Integration Tests API endpoints and application xUnit, WebApplicationFactory,
flows end-to-end against a real TestContainers or SQLite in-memory
test database.
Component Tests Individual Blazor components bUnit
(Blazor) in isolation — rendering, user
interaction, state.
Manual / Full user flows in a running Manual — document key test cases
Exploratory app. Complex UI interactions.
Edge cases not covered by
automation.

Page 1
Testing Strategy — Template

3. Coverage Targets
📝 Coverage is a guide, not a goal in itself. 80% coverage of the wrong things is worse than
60% coverage of the right things.

Layer Target Coverage Focus Areas

Domain Layer 90%+ All business rules, invariants, and domain
logic must be unit tested.
Application Layer 80%+ All command and query handlers. Test
happy path and key failure paths.
Infrastructure Layer Integration tested EF Core mappings, migrations, and
repository implementations via integration
tests.
Presentation Layer (Blazor) Key components Test critical components (auth forms,
character creation, forum post). Not every
component needs a test.

4. Test Project Structure

Recommended structure

/tests /[ProjectName].[Link] — Unit tests for domain entities and value objects
/[ProjectName].[Link] — Unit tests for commands, queries, and handlers
/[ProjectName].[Link] — Integration tests for API endpoints
/[ProjectName].[Link] — bUnit component tests

5. Naming Conventions
📝 Consistent naming makes tests easy to find and understand.

Convention Example
Test class name [ClassName]Tests — e.g. CharacterTests,
AssignExperienceCommandHandlerTests
Test method name [MethodUnderTest]_[Scenario]_[ExpectedResult]
Example: should create Create_WithValidInputs_ReturnsNewCharacter
character
Example: should reject invalid AssignExperience_WithNegativeValue_ThrowsDomainException
XP
Example: Blazor component CharacterForm_WhenSubmitted_CallsCreateCharacterComman
test d

6. Testing Security-Sensitive Features

📝 These areas require explicit test coverage because bugs here have serious consequences.

Page 2
Testing Strategy — Template

• Authorisation — test that each endpoint returns 403 when called by a role that should
not have access. Test all role combinations for sensitive endpoints.
• Authentication — test that unauthenticated requests to protected endpoints return
401. Test that expired tokens are rejected.
• GDPR data handling — test that personal data is not returned to unauthorised
callers. Test that the erasure flow removes all expected data.
• Activity logging — test that a logged action produces the correct entry with the
correct actor and timestamp.
• Character XP/Level — test that a standard user cannot call assign-xp or assign-level
endpoints.

7. Integration Test Setup

Test database approach

Describe your approach here. Options: - SQLite in-memory: fast, simple, but some SQL Server
features may behave differently. - TestContainers: spins up a real Docker database per test run.
More accurate, slightly slower. - Shared test database: fast but risks test interdependence —
avoid if possible. Recommended: TestContainers for integration tests that need to validate
migrations and SQL behaviour.

📝 Each integration test should start from a known clean state. Use database transactions that
are rolled back after each test, or recreate the schema before each test class.

8. Running Tests
Commands

# Run all tests dotnet test # Run with coverage report dotnet test --collect:"XPlat Code Coverage"
# Run only unit tests dotnet test --filter Category=Unit # Run only integration tests dotnet test --
filter Category=Integration # Run tests for a specific project dotnet test
tests/[ProjectName].[Link]

9. What We Do Not Test

To keep the test suite lean and fast, we deliberately do not test:
• Generated EF Core migration code — we test that the schema is correct via
integration tests, not the migration files themselves.
• Third-party library internals ([Link] Core Identity, MediatR, etc.).
• Trivial getters and setters with no logic.
• Configuration loading — tested implicitly by integration tests that require correct
config.

Page 3
Testing Strategy — Template

10. Test Review in PRs

All pull requests should include appropriate tests. During code review, check:
• Do the tests cover the happy path?
• Do the tests cover the key failure cases?
• Are the tests named clearly?
• Do the tests actually assert something meaningful — or do they just run without
checking output?
• For security-sensitive features: are authorisation rules tested?

Testing Strategy Template — Reenactment Society Website

Page 4