Ответ
Мой опыт с JDBC в QA связан с написанием автотестов для проверки целостности данных и состояния базы данных. Я использовал его для:
- Верификации данных после выполнения тестовых сценариев через UI или API. Например, после создания заказа через веб-интерфейс, проверял, что соответствующие записи появились в таблицах
ordersиorder_itemsс правильными статусами и суммами. - Подготовки и очистки тестовых данных напрямую в БД, минуя сервисный слой, для изоляции тестов.
- Проверки выполнения сложных бизнес-правил на уровне БД, которые сложно покрыть через API.
Пример кода для интеграционного теста (JUnit 5 + H2 in-memory DB):
@Test
public void userRegistration_ShouldPersistUserInDatabase() throws SQLException {
// 1. Подготовка: очистка таблицы перед тестом
try (Connection conn = dataSource.getConnection();
Statement stmt = conn.createStatement()) {
stmt.execute("DELETE FROM users");
}
// 2. Выполнение тестируемого действия через сервис/API
userService.register("test@example.com", "password123");
// 3. Верификация данных напрямую через JDBC
try (Connection conn = dataSource.getConnection();
PreparedStatement ps = conn.prepareStatement("SELECT email, is_active FROM users WHERE email = ?")) {
ps.setString(1, "test@example.com");
ResultSet rs = ps.executeQuery();
assertTrue(rs.next()); // Запись должна существовать
assertEquals("test@example.com", rs.getString("email"));
assertFalse(rs.getBoolean("is_active")); // Проверка бизнес-правила (требует активации)
assertFalse(rs.next()); // Должна быть только одна запись
}
}
Для управления соединениями в тестах я использовал пулы (HikariCP) и часто применял in-memory БД (H2) для скорости изоляции.