Должен ли каждый разработчик локально устанавливать базу данных для использования ее с Unit-тестами

# Должен ли каждый разработчик локально устанавливать БД для Unit-тестов

Краткий ответ

Нет, это антипаттерн. Unit-тесты должны быть изолированными и быстрыми. Использование реальной БД усложняет разработку и замедляет тесты.

Почему не использовать реальную БД в Unit-тестах

1. Скорость выполнения

Unit-тесты должны выполняться за миллисекунды. Реальная БД добавляет задержки:

• Подключение к БД
• Инициализация схемы
• Выполнение запросов

// ❌ Плохо — медленно
@Test
public void testUserRepository() {
    User user = new User("John");
    database.save(user); // Реальный INSERT в БД
    User found = database.findByName("John"); // Реальный SELECT
    assertEquals("John", found.getName());
}

2. Зависимость от окружения

Не все разработчики могут установить одинаковое окружение. Docker с контейнером БД — решение, но это усложняет процесс.

3. Изоляция тестов

Если один тест оставляет данные в БД, это может помешать другим тестам. Нужно писать код очистки, что усложняет тесты.

// ❌ Плохо — тесты зависят друг от друга
@Test
public void testCreateUser() {
    database.save(new User("Alice"));
}

@Test
public void testFindAllUsers() {
    List<User> users = database.findAll();
    assertEquals(1, users.size()); // Зависит от предыдущего теста!
}

4. Детерминированность

Порядок тестов может быть случайным. Реальная БД может быть в непредсказуемом состоянии.

Правильный подход

1. Мокирование репозитория

Для Unit-тестов используй Mockito для создания моков объектов БД:

@RunWith(MockitoJUnitRunner.class)
public class UserServiceTest {
    @Mock
    private UserRepository userRepository;
    
    @InjectMocks
    private UserService userService;
    
    @Test
    public void testGetUser() {
        User mockUser = new User("John");
        when(userRepository.findById(1L)).thenReturn(mockUser);
        
        User result = userService.getUser(1L);
        
        assertEquals("John", result.getName());
        verify(userRepository).findById(1L);
    }
}

2. H2 база данных для Integration-тестов

Если нужно тестировать реально работающий слой БД, используй встроенную H2:

@RunWith(SpringRunner.class)
@DataJpaTest
@AutoConfigureTestDatabase(replace = AutoConfigureTestDatabase.Replace.ANY)
public class UserRepositoryIntegrationTest {
    @Autowired
    private UserRepository userRepository;
    
    @Test
    public void testSaveAndFind() {
        User user = new User("Alice");
        userRepository.save(user);
        
        User found = userRepository.findByName("Alice");
        assertEquals("Alice", found.getName());
    }
}

H2 работает в памяти и автоматически очищается после каждого теста.

3. TestContainers для сложных сценариев

Для реальной PostgreSQL/MySQL в контейнерах используй TestContainers:

public class UserRepositoryTest {
    @Container
    static PostgreSQLContainer<?> postgres = new PostgreSQLContainer<>("postgres:14")
        .withDatabaseName("testdb")
        .withUsername("test")
        .withPassword("test");
    
    @Test
    public void testWithRealDatabase() {
        // Docker автоматически запустит контейнер
        // Тест исполнится против реальной БД
    }
}

Разделение на типы тестов

• Unit-тесты (без БД): мокирование репозиториев, быстрые
• Integration-тесты: H2 или TestContainers, проверка SQL-запросов
• End-to-End тесты: реальная БД с полной инициализацией

Лучшие практики

1. Unit-тесты не должны обращаться к БД
2. Используй моки для зависимостей
3. Для тестирования БД используй H2 или TestContainers
4. Разделяй Unit-тесты и Integration-тесты
5. CI/CD должна управлять окружением (Docker Compose)

Заключение

Каждый разработчик НЕ должен устанавливать реальную БД для Unit-тестов. Используй моки, H2 или TestContainers в зависимости от типа теста. Это улучшит скорость разработки и стабильность тестов.