Testing Standards for .NET

Unit Testing Requirements

• Mandatory: Unit tests are required for all business logic, commands, and handlers.

• Organization Standard: Follow the AAA (Arrange-Act-Assert) principle.

• Separation of Concerns: Create builder classes to generate all variables, objects, and data needed for unit tests. This keeps tests clean and maintainable.

• Coverage: Minimum expected code coverage is 80%.

Unit Test Example Structure

public class CreateUserCommandHandlerTests { [Fact] public async Task Handle_ValidCommand_ShouldCreateUser() { // Arrange var builder = new UserTestBuilder(); var user = builder.WithEmail("test@example.com").Build(); var command = new CreateUserCommand { Email = user.Email };

    // Act
    var result = await _handler.Handle(command, CancellationToken.None);
    
    // Assert
    result.Should().NotBeNull();
    result.Email.Should().Be(user.Email);
}

}

Integration Testing Standards (Agaval Standard)

• Required: Integration tests are required to verify API endpoint functionality and cross-layer interactions.

• Persistence Isolation: Priority is to use in-memory databases (e.g., EF Core In-Memory) for integration tests. NEVER use development/production environment databases.

• API and Startup: API orchestration and startup must always be done using WebApplicationFactory .

• External Service Simulation: Simulate external services (APIs, Brokers, etc.) using WireMockServer or similar mock objects to ensure test isolation.

• Separation of Concerns: Create a class called WebApplicationTestFactory and establish all the previously mentioned configurations and necessary settings for tests there.

Integration Test Example Structure

public class WebApplicationTestFactory : WebApplicationFactory<Program> { protected override void ConfigureWebHost(IWebHostBuilder builder) { builder.ConfigureServices(services => { // Remove the real database context var descriptor = services.SingleOrDefault( d => d.ServiceType == typeof(DbContextOptions<AppDbContext>)); if (descriptor != null) services.Remove(descriptor);

        // Add in-memory database
        services.AddDbContext<AppDbContext>(options =>
        {
            options.UseInMemoryDatabase("TestDb");
        });

        // Replace external services with mocks
        services.AddSingleton<IExternalService, MockExternalService>();
    });
}

}

public class UserEndpointTests : IClassFixture<WebApplicationTestFactory> { private readonly HttpClient _client;

public UserEndpointTests(WebApplicationTestFactory factory)
{
    _client = factory.CreateClient();
}

[Fact]
public async Task GetUsers_ShouldReturnOk()
{
    // Arrange & Act
    var response = await _client.GetAsync("/api/users");
    
    // Assert
    response.StatusCode.Should().Be(HttpStatusCode.OK);
}

}

Test Builder Pattern

Create dedicated builder classes for complex test data:

public class UserTestBuilder { private string _email = "default@test.com"; private string _name = "Test User";

public UserTestBuilder WithEmail(string email)
{
    _email = email;
    return this;
}

public UserTestBuilder WithName(string name)
{
    _name = name;
    return this;
}

public User Build()
{
    return new User
    {
        Email = _email,
        Name = _name
    };
}

}

Best Practices

• Keep tests independent and isolated.

• Use meaningful test names that describe the scenario.

• Mock external dependencies properly.

• Clean up test data after each test run.

• Use assertion libraries like FluentAssertions for readable assertions.