Testing Strategy

Relevant source files

• .github/workflows/CI-BuildAndTest.yml
• .github/workflows/dotnet.yml
• .gitignore
• CODE_COVERAGE.md
• Docker/docker-compose.yml
• src/Audit.HttpClient/Properties/AssemblyInfo.cs
• src/Audit.NET.AzureStorageTables/Properties/AssemblyInfo.cs
• test/Audit.AspNetCore.UnitTest/SignalRTests.cs
• test/Audit.AzureCosmos.UnitTest/Audit.AzureCosmos.UnitTest.csproj
• test/Audit.AzureCosmos.UnitTest/AzureCosmosTests.cs
• test/Audit.AzureEventHubs.UnitTest/AzureEventHubsTests.cs
• test/Audit.AzureStorageTables.UnitTest/AzureTableDataProviderIntegrationTests.cs
• test/Audit.RavenDB.UnitTest/RavenDbDataProviderTests.cs
• test/Audit.Redis.UnitTest/RedisTests.cs
• test/AzureSettings.cs

Purpose and Scope

This document describes the comprehensive testing approach for Audit.NET, including test organization, integration test infrastructure, execution strategies, and code coverage practices. The testing strategy ensures reliable validation across 45+ assemblies and 376+ classes with 89.4% line coverage.

For information about the CI/CD pipelines that execute these tests, see CI/CD Infrastructure. For details on multi-framework targeting that affects test execution, see Multi-Framework Support. For code quality metrics and analysis, see Code Quality and Coverage.

---

Test Organization

Test Project Structure

The test suite is organized into dedicated test projects that correspond to production assemblies:

Test Project Pattern	Production Assembly	Purpose
Audit.*.UnitTest	Audit.*	Unit and integration tests for specific packages
test/TestResult/	N/A	Test execution results and coverage reports

Each test project targets multiple frameworks to validate cross-platform compatibility:

netcoreapp3.1, net6.0, net462

Sources: .github/workflows/CI-BuildAndTest.yml98-106 test/Audit.AzureCosmos.UnitTest/Audit.AzureCosmos.UnitTest.csproj4

Test Types

Tests are organized into two primary categories:

1. Unit Tests: Fast, isolated tests that validate individual components without external dependencies
2. Integration Tests: Tests that interact with real external services via Docker containers

---

Test Categorization System

NUnit Category Attributes

Tests use NUnit's [Category] attribute to enable selective test execution:

Category Usage Examples

Integration tests combine categories to indicate requirements:

Sources: test/Audit.AzureCosmos.UnitTest/AzureCosmosTests.cs20-24 test/Audit.Redis.UnitTest/RedisTests.cs13-16 test/Audit.RavenDB.UnitTest/RavenDbDataProviderTests.cs15-18

CI Test Execution Filters

Tests are filtered during CI execution using category combinations:

Sources: .github/workflows/CI-BuildAndTest.yml214-215 .github/workflows/CI-BuildAndTest.yml52-54

---

Integration Test Infrastructure

Docker Compose Service Architecture

Integration tests rely on 14 containerized services orchestrated via Docker Compose:

Docker Compose Configuration

The complete service stack is defined in a single compose file:

File: Docker/docker-compose.yml

Key services include:

• immudb: Port 3322 with persistent volume Docker/docker-compose.yml2-9
• dynamodb: Port 8000 with shared DB mode Docker/docker-compose.yml11-15
• postgresql: Port 5432 with init script Docker/docker-compose.yml17-27
• mysql: Port 3306 with init script Docker/docker-compose.yml29-37
• redis: Port 6379 Docker/docker-compose.yml39-42
• elasticsearch: Port 9200, security disabled Docker/docker-compose.yml44-51
• opensearch: Port 9250, security disabled Docker/docker-compose.yml53-64
• mongodb: Port 27017 with persistent volume Docker/docker-compose.yml66-71
• ravendb: Port 8080, unsecured access Docker/docker-compose.yml73-78
• azurite: Ports 10000-10002 for blob/queue/table Docker/docker-compose.yml80-90
• eventhubs-emulator: Ports 5672, 9092, depends on azurite Docker/docker-compose.yml92-108
• cosmosdb-emulator: Port 8082 Docker/docker-compose.yml110-121
• sqlserver: Port 1433 with health check Docker/docker-compose.yml123-133
• kafka: Port 9094 Docker/docker-compose.yml135-147

Sources: Docker/docker-compose.yml1-160

Service Startup and Health Checks

The CI pipeline ensures all services are available before running tests:

Sources: .github/workflows/CI-BuildAndTest.yml127-162

---

Test Execution Strategy

Multi-Platform CI Execution

Tests execute across two separate CI jobs to accommodate platform-specific requirements:

Platform-Specific Test Execution

Windows Job (build-and-test-windows):

• Runs on: windows-latest
• Executes: Tests categorized as MonoIncompatible
• No external services required
• Faster execution for compatibility-specific tests

Linux Job (build-and-test-linux):

• Runs on: ubuntu-22.04
• Executes: All tests except MonoIncompatible
• Requires: All 14 Docker Compose services
• Timeout: 60 minutes
• Includes: SonarCloud analysis and code coverage

Sources: .github/workflows/CI-BuildAndTest.yml17-55 .github/workflows/CI-BuildAndTest.yml57-250

Test Parallelization

Tests execute with limited parallelization to avoid resource contention:

The -m:1 flag limits parallel execution to avoid port conflicts and resource exhaustion across 14 containerized services.

Sources: .github/workflows/CI-BuildAndTest.yml212-215

---

Test Configuration and Connection Strings

TestCommon Configuration Class

Centralized test configuration provides connection strings and service endpoints:

Sources: test/AzureSettings.cs5-27

Integration Test Connection Patterns

Tests connect to local services using consistent patterns:

Redis:

test/Audit.Redis.UnitTest/RedisTests.cs18

RavenDB:

test/Audit.RavenDB.UnitTest/RavenDbDataProviderTests.cs20

Azure Cosmos DB:

test/Audit.AzureCosmos.UnitTest/AzureCosmosTests.cs28-36

---

Code Coverage Metrics

Current Coverage Statistics

The test suite achieves comprehensive coverage across the codebase:

Metric	Value	Details
Line Coverage	89.4%	10,552 of 11,790 coverable lines
Branch Coverage	80%	3,857 of 4,817 branches
Assemblies	45	All production packages
Classes	376	Core and extension classes
Files	330	Source files analyzed

Sources: CODE_COVERAGE.md11-18

Coverage by Assembly

High-coverage assemblies (>95%):

Assembly	Line Coverage	Branch Coverage
Audit.FileSystem	100%	100%
Audit.EntityFramework.Identity	100%	N/A
Audit.NET.JsonNewtonsoftAdapter	100%	97.5%
Audit.NET.PostgreSql	99.5%	93%
Audit.AzureFunctions	98.4%	82.8%
Audit.NET.Firestore	98.1%	88.4%
Audit.HttpClient	97.5%	90.6%
Audit.MediatR	97.5%	77.4%

Sources: CODE_COVERAGE.md28-199

Coverage Reporting

Coverage reports are generated using reportgenerator:

Results are:

1. Uploaded as CI artifacts
2. Committed to repository as CODE_COVERAGE.md
3. Analyzed by SonarCloud

Sources: .github/workflows/CI-BuildAndTest.yml227-229

Risk Hotspots

The coverage report identifies high-complexity methods requiring attention:

Assembly	Class	Method	Crap Score	Cyclomatic Complexity
Audit.Wcf.Client	AuditMessageInspector	CreateWcfClientAction	272	16
Audit.Wcf.Client	AuditMessageInspector	AfterReceiveReply	210	14
Audit.Mvc.Core	AuditAttribute	GetResponseBody	147	36
Audit.EntityFramework	DbContextHelper	SetConfig	100	100

Sources: CODE_COVERAGE.md21-75

---

Test Patterns and Best Practices

Integration Test Setup Pattern

Tests follow a consistent setup/act/assert pattern with proper resource cleanup:

Sources: test/Audit.AzureCosmos.UnitTest/AzureCosmosTests.cs25-83

Async Test Pattern

Async tests follow similar patterns with proper disposal:

Sources: test/Audit.AzureEventHubs.UnitTest/AzureEventHubsTests.cs153-190

Mocking External Dependencies

Unit tests use Moq to isolate dependencies:

Sources: test/Audit.AzureCosmos.UnitTest/AzureCosmosTests.cs312-348

---

Summary

The Audit.NET testing strategy employs:

• Comprehensive Coverage: 89.4% line coverage across 45 assemblies
• Dual-Platform Execution: Separate Windows/Linux CI jobs for compatibility
• Rich Integration Testing: 14 containerized services via Docker Compose
• Systematic Categorization: NUnit categories for selective test execution
• Automated Quality Gates: SonarCloud analysis and coverage reporting
• Consistent Patterns: Standardized setup/act/assert with proper cleanup

This approach ensures reliable validation of core functionality, extension packages, and data provider integrations across multiple .NET versions and platforms.