Комментарии 8
Мы в API отказались от большого количества unit-тестов в пользу большого количества интеграционных/модульных тестов,
unit-тест как раз переводится на русский как модульный тест
Но ведь если у вас мало юнит тестов и много интеграционных тестов, это получается ice cream cone. Что не очень хорошо.
Ice cream это когда больше всего e2e тестов, а много интеграционных - это "кубок" (trophy), который порой считается эффективнее классической пирамиды
Неплохая идея. В SQL Server есть механизм снепшотов, по сути такие сейв-пойнты, можно сделать снепшот и после теста вернутся в исходное состояние и обойтись без рестартов, может есть ли что-либо похоже в postgresql?
Стоит отметить, что гоняя тесты таким образом невозможно получить итоговый coverage
В лоб невозможно. Однако, можно из каждой параллельной джобы тестов выгрузить артефакты покрытия, в отдельном шаге их получить, объединить и посчитать покрытие
Эта статья была написана как ответ на переписку в комментариях к моей статье: https://habr.com/ru/articles/742552/
И вот у меня дошли руки тоже это реализовать у себя :) Делюсь прогрессом.
Подход выбран близкий, но с отличиями в деталях. Поднимается контекст Spring, считаем sha256 от папки с миграциями liquibase, часть первых символов в hex это тег образа. Если образа нет, собираем: подняли стандартный контейнер postgresql, запустили миграции liquibase, стопнули контейнер, скопировали /var/lib/postgresql/data в отдельный .tar.gz, создаём на основе стандартного postgresql новый образ с нужным тегом, закидывая туда файлы в другую папку (/var/lib/postgresql-migrated/data) + обновлённый migrated-entrypoint.sh. Скрипт делает только перемещение в изначальную папку, и запуск оригинального docker-entrypoint.sh, это нужно для того, чтобы файлы в контейнере разместились на tmpfs.
При запуске одного произвольного теста время на поднятие контекста срезалось в два раза.
Публикации
Как мы поднимаем dev-стэнд(ы) и гоняем полноценные тесты api на каждый коммит