IvanVakhrushev May 11 2020 at 19:42

Шесть советов об использовании PostgreSQL в функциональных тестах

5 min

15K

PostgreSQL*Java*Web services testing*

+18

Comments 12

VanquisherWinbringer May 11 2020 at 21:59

Эка годнота какая. Плюс вам за старания. Хотя мне больше нравилось когда автотестеры такие тысты писали. E2E aka Функциональные. Мне как разработчику хочется Unit тесты написать и дальше уже отдавать автоматам. Ну это такое, не все всегда бывает как мы того хотим.

tbl May 11 2020 at 22:07

В unit-тестах тоже базу можно подымать. Т.е. чем ближе окружение тестов к проду, тем они реальнее тестируют код. А то так все замокать можно, и выплеснуть воду с младенцем.

-1

lngtmg May 17 2020 at 16:55

Нынче все больше и больше продуктов идут с Continuous Deployment.
При этом разделение на разработчиков и автоматизаторов становится не актуальным — разработчик сам пишет и код и Е2Е тесты. Когда инфраструктурный код для Е2Е уже есть (привет девопсам) написание Е2Е теста — дело не хитрое :)

JeriC4o May 12 2020 at 08:16

Хорошая статья, дельные советы.

vlanko May 14 2020 at 21:58

А почему тесты на время стали падать именно в 11й?

IvanVakhrushev May 15 2020 at 11:05

Триггером стало изменение точности во внутреннем формате представления времени в Java 11.
А по факту, конечно, проблема в коде и тестах на него.

Таких проблем вообще много бывает. Как-то раз обновляли версию jdbc-драйвера для Постгреса. Тесты прошли, а в одном из окружений спринговый контекст не поднялся — приложение не смогло к БД подключиться. Оказалось, что на хостах нет нужных SSL-сертификатов, а раньше работало из-за баги в драйвере. Обновили драйвер, бага ушла — у нас всё сломалось.
Release notes нужно читать :)

lngtmg May 17 2020 at 20:18

Спасибо за совет с truncate для всех таблиц сразу.
Увы, не всегда применим. Например, если в некоторых таблицах нужно оставить отдельные записи — тут уж только delete from where.

Мы пошли другим путем (сразу оговорюсь — запускаем PG в докере):

используем delete
добавляем все в батч
выключаем все что можно выключить в postgresql.conf
```
fsync = off
synchronous_commit = off
full_page_writes = off
autovacuum = off
```

IvanVakhrushev May 19 2020 at 12:29

А чек-поинты тюнили? Вдруг будет полезно Дорогой DELETE / Николай Самохвалов (Postgres.ai)

lngtmg May 19 2020 at 13:02

Насколько я понимаю, это имеет смысл делать когда в тестах гоняются большие объемы данных (больше данных -> больше WAL -> чаще срабатывают чекпоинты).
Не наш случай, но спасибо за линку. Николай всегда интересен )

neumond May 19 2020 at 12:22

Я бы ещё посоветовал вместо очистки по окончанию теста делать очистку перед тестом. Во-первых, если тест упал можно подсмотреть что в БД. Во-вторых, если процесс с тестами был убит с помощью сигналов, например если завис, то при следующем запуске не будет падения из-за нестёртых данных.

И ещё, очень полезно рандомизировать все сиквенсы перед тестами, каждый id будет начинаться со случайного большого числа, и в тестах исчезнет риск сравнить id апельсинов c id крокодилов.

IvanVakhrushev May 19 2020 at 12:46

Рандомизация сиквенсов у нас есть, но не везде — пока что не оформили как системное решение. Можно начинать сиквенсы, например, с Integer.MAX_VALUE + 1. Это позволяет отловить баги, когда в связанных таблицах используются неправильные типы — int вместо bigint. Но тут есть и обратная сторона медали — человекочитаемость снижается, дебажить код не так удобно из-за больших чисел.
Из-за сиквенсов перестали беспокоиться, когда сделали нормальную ссылочную целостность.

vlanko May 23 2020 at 22:23

10_000_000_000 может будет читаемее?

Show the best of all time