Какой подход применишь для покрытия тестами БД?

Стратегия тестирования взаимодействия с базой данных (Backend C#)

Для эффективного покрытия тестов баз данных в C# Backend я применяю многоуровневый подход, сочетающий различные типы тестов для баланса надежности, скорости и изоляции. Основная цель — обеспечить корректность бизнес-логики, работающей с данными, без излишней зависимости от конкретной физической БД в большинстве сценариев.

Основные принципы и уровни тестирования

Ключевой принцип: максимальное использование модульных тестов (Unit tests) с подменой зависимостей через моки (Mock) и стабы (Stub) для слоя доступа к данным, дополненное интеграционными тестами (Integration tests) с реальной или тестовой БД для критических сценариов.

1. Модульное тестирование слоя бизнес-логики (с изоляцией от БД)

Для тестирования сервисов, обработчиков команд или контроллеров, которые используют репозитории или DbContext, я применяю подмену зависимостей. Используются библиотеки, такие как Moq или NSubstitute, для создания моковых объектов IRepository или IDbContext.

// Пример: Сервис, зависящий от репозитория
public class UserService
{
    private readonly IUserRepository _repository;
    public UserService(IUserRepository repository) => _repository = repository;
    
    public User GetActiveUser(int id)
    {
        var user = _repository.GetById(id);
        if (user == null || !user.IsActive) 
            throw new NotFoundException();
        return user;
    }
}

// Тест с использованием Moq
[Test]
public void GetActiveUser_Throws_WhenUserNotFound()
{
    // Arrange
    var mockRepo = new Mock<IUserRepository>();
    mockRepo.Setup(r => r.GetById(1)).Returns(null); // Стабируем поведение
    var service = new UserService(mockRepo.Object);
    
    // Act & Assert
    Assert.Throws<NotFoundException>(() => service.GetActiveUser(1));
    mockRepo.Verify(r => r.GetById(1), Times.Once); // Проверяем взаимодействие
}

Преимущества: тесты быстрые, не требуют БД, легко запускаются в CI/CD. Они проверяют бизнес-логику в изоляции.

2. Интеграционные тесты для слоя доступа к данным (Repository/DbContext)

Для проверки корректности запросов к БД (LINQ, SQL) и работы с DbContext необходимы тесты с реальной базой данных в памяти (in-memory) или легкой тестовой БД (например, SQLite в режиме памяти). Это позволяет убедиться в правильности маппинга и формирования запросов.

// Пример интеграционного теста с EF Core и SQLite in-memory
[Test]
public async Task Repository_GetById_ReturnsCorrectUser()
{
    // Arrange: Создаем временную БД в памяти
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseSqlite("DataSource=:memory:")
        .Options;
    
    using var context = new AppDbContext(options);
    await context.Database.OpenConnectionAsync();
    await context.Database.EnsureCreatedAsync(); // Создаем схему
    
    var testUser = new User { Id = 1, Name = "Test" };
    await context.Users.AddAsync(testUser);
    await context.SaveChangesAsync();
    
    var repository = new UserRepository(context);
    
    // Act
    var result = await repository.GetById(1);
    
    // Assert
    Assert.AreEqual("Test", result.Name);
}

Примечание: можно использовать EF Core InMemory provider, но он не полностью эмулирует реляционную БД (например, не поддерживает транзакции, некоторые SQL-операции). SQLite более надежен для таких тестов.

3. Тесты транзакций и сложных сценариев

Для критических операций (транзакции, миграции, сложные JOIN) иногда необходимы тесты с реальной, но временной БД (например, локальной PostgreSQL или SQL Server), которая разворачивается перед тестом и очищается после. Здесь применяются Docker или LocalDB для автоматизации.

// Пример с использованием Testcontainers для Docker-базы
public class DatabaseIntegrationTests
{
    private readonly PostgreSQLContainer _dbContainer = 
        new PostgreSQLBuilder().Build();

    [OneTimeSetUp]
    public async Task Setup() => await _dbContainer.StartAsync();

    [Test]
    public async Task ComplexQuery_WorksWithRealPostgres()
    {
        var connString = _dbContainer.GetConnectionString();
        using var context = new AppDbContext(new DbContextOptionsBuilder()
            .UseNpgsql(connString).Options);
        
        // ... выполнение и проверка сложного запроса
    }
}

Важно: такие тесты медленнее и требуют инфраструктуры, поэтому их количество должно быть ограничено ключевыми сценариями.

Организация тестов: именование и структура

• Модульные тесты: располагаются в проекте .Tests.Unit, используют моки.
• Интеграционные тесты: в проекте .Tests.Integration, работают с легкой БД.
• Тесты с реальной БД: в проекте .Tests.Database (или отдельный набор).

Практические рекомендации

• Используйте транзакции с откатом в интеграционных тестах для очистки данных без удаления таблиц.
• Тестируйте миграции EF Core отдельно, проверяя успешность применения DbContext.Database.Migrate().
• Для сложных хранимых процедур применяйте подход с реальной БД или используйте моки для DbCommand.
• Избегайте тестирования тривиальных методов CRUD (например, простой Save), фокусируясь на логике и сложных запросах.
• Автоматизируйте очистку тестовой БД после каждого теста или набора.

Баланс между покрытием и скоростью

Идеальное соотношение:

• 80-90% модульных тестов с полной изоляцией от БД.
• 10-15% интеграционных тестов с in-memory или SQLite.
• 0-5% тестов с реальной БД для критической функциональности.

Этот подход обеспечивает высокую скорость выполнения тестовой сборки (что важно для CI/CD), хорошее покрытие и достаточную уверенность в работе с данными. При этом он минимизирует хрупкость тестов, связанную с состоянием и доступностью внешней БД.