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

[VanquisherWinbringer]

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

[tbl]

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

[lngtmg]

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

[JeriC4o]

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

[vlanko]

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

[IvanVakhrushev]

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

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

[lngtmg]

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

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

• используем delete
• добавляем все в батч
• выключаем все что можно выключить в postgresql.conf
  

  fsync = off
  synchronous_commit = off
  full_page_writes = off
  autovacuum = off

[IvanVakhrushev]

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

[lngtmg]

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

[neumond]

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

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

[IvanVakhrushev]

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

[vlanko]

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