Подход к интеграционному тестированию #18
Conversation
| ### Описание подхода | ||
| 1. Для выполнения интеграционного тестирования предлагается использовать отдельный тестовый стенд, а не пытаться запускать контейнеры на машине с агентом сборки. Это позволит уменьшить нагрузку на сервер сборки. Таким образом у прикладного проекта должен быть подготовленный "сервер", на котором будет осуществляться автоматизированное интеграционное тестирование | ||
| 2. Касательно БД есть два варианта: | ||
| 1. **Без Docker**. На подготовленном сервере для интеграционного тестирования есть "эталонная" БД `etalon_db` с нужной схемой таблиц и нужными данными |
There was a problem hiding this comment.
Это дев БД или подразумевается наличие отдельной БД сугубо для тестирования? Если отдельной, то в рамках генерируемого CI/CD нет речи о поддержании дев БД равной эталону? Или по каким принципам это должно происходить?
There was a problem hiding this comment.
Концепция dev БД за рамками этого RFC. У нас в частности dev БД содержит кучу левых таблиц и данных. В эталонной БД по задумке должен быть лишь необходимый минимум данных. А поддержание схемы дев БД равной схеме эталонной БД можно обеспечить тем же самым билдом, который после мержа должен будет на эталонную БД скрипты изменения накатывать
| * Запускать контейнеры с БД и с бекендом можно прямо на агенте сборки. Данный вариант кажется хуже, потому что ресурсы агента ограничены и будет выше шанс влияния соседних билдов | ||
|
|
||
| ## Нерешенные вопросы | ||
| * Не описано каким образом должны в репозитории располагаться скрипты изменения БД, чтобы их было возможно применять описанным способом |
There was a problem hiding this comment.
Не подразумевается использование Liquidbase / деление на Liquidbase/какие-либо еще миграции и DML скрипты?
There was a problem hiding this comment.
Если все проголосуют за liquibase, можно его принять. Но мне не нравятся его ограничения и лишняя зависимость. У нас простой скрипт
if not exists(select 1 from migrations where id='id')
begin
insert into migrations 'id';
--actual script;
end
Работает хорошо, а если такое еще и генерить из дизайнера, вообще шикарно было бы
There was a problem hiding this comment.
Мы тоже у себя думали в сторону аналогичных скриптов (правда до того как про liquidbase узнали), плюс если я правильно понимаю он не хранит скрипты, а что-то типа XML схемы миграций, скрипты в этом плане кажутся удобнее (или просто привычнее)
There was a problem hiding this comment.
Тема старая, но я голосую за Liquibase. Мы недавно начали его использовать на ТПлюс, пока всё нравится.
mao29
force-pushed
the
feature-integration-testing-infrastructure
branch
from
d42f23e
to
12f9fb4
Compare
There was a problem hiding this comment.
Я бы включил liquibase как обязательный элемент архитектуры интеграционных тестов. Дополнительно надо прописать необходимость иметь docker-compose-файлы для запуска бакенда (и фронтенда) для прогона тестов на локальном компьютере.
Дополнительно хочу обратить внимание вот на такой пример - он позволяет выполнять тесты изолированно друг от друга и понятным образом подменяет строку соединения на каждый тест. Если движемся в эту сторону, то надо генерировать базовый класс для всех интеграционных тестов, который будет готовить инфраструктуру правильным образом.
|
|
||
| ## Краткое описание | ||
|
|
||
| Предлагается заложить в генерируемые из Flexberry Designer приложения единый подход, облегчающий быстрый старт и настройку CI/CDL для интеграционного тестирования этих приложений. Рассматривается только случай, когда приложение состоит из фронтенда и бекенда, исходный код которых располагается в одном репозитории, а интеграционные тесты задействуют БД. Сценарии интеграционного тестирования взаимодействия нескольких сервисов или взаимодействия с брокером сообщений выходят за рамки данного RFC. |
There was a problem hiding this comment.
Насколько хорошей является практика, когда фронтенд и бакенд располагаются в одном репозитории? Какие аргументы за, а какие против этой схемы?
There was a problem hiding this comment.
Мне кажется технология подталкивает к тому, чтобы было именно так. Если для выполнения задачи требуется перегенерация, обычно затрагивается и фронт и бек. Генератор предполагает определенную структуру папок относительно пути генерации стадии. Кроме того иметь изменения по задаче одним коммитом в репозиторий удобнее, чем разными в разные репозитории. CI/CD инструменты позволяют гранулярно выполнять проверки и билды в зависимости от путей к измененным файлам.
Когда в студии создаешь проект на ASP.NET там файлы фронта прямо в проект генерируются тоже, так что считаю практика хорошая
|
|
||
| ### Требования | ||
| Данный RFC предполагает соблюдение следующих требований: | ||
| * Фронтенд и бекенд находятся в одном репозитории |
There was a problem hiding this comment.
Чисто технически такого ограничения нет. У нас есть пример интеграционных тестов, когда фронтенд и бакенд живут в разных репозиториях. Более того, бакенды могут иметь разные реализации и за счёт корректно оформленного api могут быть заменяемыми.
There was a problem hiding this comment.
Это требование данного RFC. Вариантов может быть множество, предлагаю начать с какого-то конкретного. Разные реализации бекендов тоже могут находиться в одном репозитории, не вижу почему это плохо
There was a problem hiding this comment.
Это не будет проверяться, дефолтный билд-пайплайн будет рассчитывать на определенную структуру папок в репозитории, чтобы и фронт и бек был. Без этого придется в пайплайне для фронта каким-то образом находить соответствующий той же задаче ПР для бекенда и собирать и развертывать его из этого ПР-а
| * Для запуска сервисов возможно использование docker | ||
| * Для выполнения интеграционных тестов необходима подготовленная база данных, содержащая как минимум все необходимые таблицы, а желательно еще и записи в таблицах справочников/реестров/полномочий | ||
| * Если PR/MR содержит скрипты изменения БД, они должны применяться на БД, создаваемую для тестов, перед запуском тестом | ||
| * После принятия PR/MR, содержащего скрипты изменения БД, для всех последующих запусков тестов должна создаваться БД, на которой эти скрипты уже применены |
There was a problem hiding this comment.
Очень похоже на предыдущий пункт. Надо подумать как переформулировать во что-то общее, либо более конкретно разделить их.
There was a problem hiding this comment.
На мой взгляд непохоже. Если есть предложение по переформулировке, закидывай suggestion
There was a problem hiding this comment.
Возможно, тут стоит прописать порядок формирования новых снапшотов базы.
There was a problem hiding this comment.
В этом пункте как раз и прописан этот порядок. Что после того как ПР смержили, если в нем были скрипты изменения БД, они должны примениться на "снепшот" БД для тестирования
| * Для выполнения интеграционных тестов необходима подготовленная база данных, содержащая как минимум все необходимые таблицы, а желательно еще и записи в таблицах справочников/реестров/полномочий | ||
| * Если PR/MR содержит скрипты изменения БД, они должны применяться на БД, создаваемую для тестов, перед запуском тестом | ||
| * После принятия PR/MR, содержащего скрипты изменения БД, для всех последующих запусков тестов должна создаваться БД, на которой эти скрипты уже применены | ||
| * Каждый интеграционный тест создает для себя в БД нужное состояние, однако БД общая для разных интеграционных тестов в рамках одного запуска. То есть, если на проекте активировано многопоточное исполнение тестов, код тестов должен предусматривать возможность наличия в БД данных, созданных соседними тестами, и это не должно приводить к падению тестов. После выполнения тест должен удалить из БД свои тестовые данные. |
There was a problem hiding this comment.
А это вопрос: на каждый тест поднимаем БД или одна БД на все тесты. Многолетний опыт нам подсказал, что лучше чуть дольше ждать исполнения всех тестов, но изоляцию получить на уровне всей БД. Иначе очень легко можно получить косвенное влияние одного теста на другой и портатить ценное время впустую.
There was a problem hiding this comment.
БД с большим количеством справочников не насоздаешься на 1000+ тестов. Нужно учиться писать тесты таким образом, чтобы друг на друга не влияли
There was a problem hiding this comment.
Как вариант, можно подумать в сторону тестовой БД без предзаполненных справочников. То есть часть тестов могут выполняться на "лёгкой" БД, в которой нет ничего кроме структуры - в этом случае тест имеет свою БД каждый раз, другая же часть тестов будет иметь общую БД со справочниками - тут уже к тестам будут требования "не мешаться другим".
There was a problem hiding this comment.
В реальных приложениях в БСах бывает логика, завязанная на справочные ключи. И в итоге при добавлении этой связки могут начать ломаться ранее проходившие на пустой БД тесты
| * После принятия PR/MR, содержащего скрипты изменения БД, для всех последующих запусков тестов должна создаваться БД, на которой эти скрипты уже применены | ||
| * Каждый интеграционный тест создает для себя в БД нужное состояние, однако БД общая для разных интеграционных тестов в рамках одного запуска. То есть, если на проекте активировано многопоточное исполнение тестов, код тестов должен предусматривать возможность наличия в БД данных, созданных соседними тестами, и это не должно приводить к падению тестов. После выполнения тест должен удалить из БД свои тестовые данные. | ||
| * Параллельно могут выполняться несколько запусков интеграционных тестов, у каждого запуска должна быть своя БД | ||
| * Если в тестовом запуске какие-то тесты упали, БД, созданная для этого тестового запуска, не должна удаляться автоматически, чтобы была возможность исследовать состояние, приведшее к падению (*хотя в данном случае гарантий все равно нет, потому что более поздний успешный тест может удалить и данные упавшего*) |
There was a problem hiding this comment.
Обычно достаточно получить информацию о том, что тест упал. Нужна ли будет БД - вопрос открытый. Обычно по коду понятно в чём дело, не помню случаев, когда приходилось ковыряться непосредственно в БД.
There was a problem hiding this comment.
Предлагаю вариант:
Делить все тесты на небольшое количество групп. Группы имеют индивидуальные базы и могут исполняться параллельно. В рамках группы тесты выполняются последовательно. Если какой-то тест в группе падает, то выполнение последующих тестов группы прекращается, а база остаётся в состоянии на момент падения.
There was a problem hiding this comment.
Мне кажется, если тесты создают для себя структуры в БД - то этот пункт лишний, т.к. мы всегда можем по коммиту - воссоздать БД на момент выполнения теста
There was a problem hiding this comment.
Ок, про сохранение БД уберу. Пропишу тогда шаг удаления тестовой БД обязательный в каждом запуске пайплайна
| * Каждый интеграционный тест создает для себя в БД нужное состояние, однако БД общая для разных интеграционных тестов в рамках одного запуска. То есть, если на проекте активировано многопоточное исполнение тестов, код тестов должен предусматривать возможность наличия в БД данных, созданных соседними тестами, и это не должно приводить к падению тестов. После выполнения тест должен удалить из БД свои тестовые данные. | ||
| * Параллельно могут выполняться несколько запусков интеграционных тестов, у каждого запуска должна быть своя БД | ||
| * Если в тестовом запуске какие-то тесты упали, БД, созданная для этого тестового запуска, не должна удаляться автоматически, чтобы была возможность исследовать состояние, приведшее к падению (*хотя в данном случае гарантий все равно нет, потому что более поздний успешный тест может удалить и данные упавшего*) | ||
| * Если все тесты выполнились успешно, БД, созданная для тестирования, должна удаляться |
There was a problem hiding this comment.
К сожалению, современные СУБД настолько умные, что не удаляют БД сразу, а начинают длительную процедуру удаления, которая в некоторых случаях затягивается очень. Короче, нужен скрипт, который будет удалять тестовые БД на указанном сервере. Если используется docker с удалением состояния - это хорошо, но иногда приходится пользоваться чем-то более стабильным (есть причины), в этом случае надо иметь возможность удалить мусор.
There was a problem hiding this comment.
Не сталкивался с подобным. У нас билд по описанной схеме ни разу не испытывал проблем с удалением тестовой БД.
There was a problem hiding this comment.
Возможно, перед удалением имеет смысл явно отключить всех пользователей и перевести базу в оффлайн, тогда не будет длительных процедур.
| * Параллельно могут выполняться несколько запусков интеграционных тестов, у каждого запуска должна быть своя БД | ||
| * Если в тестовом запуске какие-то тесты упали, БД, созданная для этого тестового запуска, не должна удаляться автоматически, чтобы была возможность исследовать состояние, приведшее к падению (*хотя в данном случае гарантий все равно нет, потому что более поздний успешный тест может удалить и данные упавшего*) | ||
| * Если все тесты выполнились успешно, БД, созданная для тестирования, должна удаляться | ||
| * Интеграционные тесты должно быть можно просто запустить на локальной машине разработчика из IDE (возможно с использованием терминала) |
There was a problem hiding this comment.
Я бы перефразировал: нужна возможность запуска тестов как из IDE, так и при помощи готовых cmd и shell-скриптов на машине разработчика.
There was a problem hiding this comment.
А ещё я бы добавил про необходимость наличия readme.md с описанием процесса запуска тестов: что там под капотом.
There was a problem hiding this comment.
Мне кажется только из IDE сложно будет запустить тесты, если требуется предварительно создать тестовую БД. ИДЕ такого не умеет, ну либо нужно колдунство с кастомными build.targets
There was a problem hiding this comment.
у нас создание тестовой бд делается в testfixture (xunit), которая вешается атрибутом на классы с тестами.
соответственно, запускается и в ide и в билде в azure. мы запускаем несколько тестов на одной тестовой бд.
There was a problem hiding this comment.
Чтобы не было проблем с платформозависимостью все тесты придётся прогонять в докере, подозреваю. Это нормально?
There was a problem hiding this comment.
Вроде xunit платфомонезависим сравнительно
| * Интеграционные тесты должно быть можно просто запустить на локальной машине разработчика из IDE (возможно с использованием терминала) | ||
|
|
||
| ### Описание подхода | ||
| 1. Для выполнения интеграционного тестирования предлагается использовать отдельный тестовый стенд, а не пытаться запускать контейнеры на машине с агентом сборки. Это позволит уменьшить нагрузку на сервер сборки. Таким образом у прикладного проекта должен быть подготовленный "сервер", на котором будет осуществляться автоматизированное интеграционное тестирование |
There was a problem hiding this comment.
Понятие тестовый стенд уже заезжено настолько, что непонятно что тут имеется в виду. Если речь про выделенную виртуальную инфраструктуру под задачи прогона интеграционных тестов, то так и надо написать.
There was a problem hiding this comment.
Выделенная виртуальная инфраструктура мне менее понятно, чем тестовый стенд. Какие разночтения могут быть в термине "тестовый стенд"? Виртуальность инфраструктуры вовсе необязательное требование, можно и на железном сервере иметь тестовый стенд и на обычном системнике, есть же примеры
There was a problem hiding this comment.
У нас используется понятие "тестовый стенд" в виде отдельного проекта, который включает в себя технологические компоненты. Это не из области инфраструктуры может быть, а некоторая логическая сущность для тестов.
There was a problem hiding this comment.
хелп gitlab'a пишет что это норм - https://docs.gitlab.com/ee/ci/services/
There was a problem hiding this comment.
Мне кажется что технологический "тестовый стенд" это не совсем стандартное использование термина. Он все-таки скорее демонстрационный стенд, либо sample. Никаких "тестов" по факту на этом стенде не осуществляется
There was a problem hiding this comment.
Мне кажется что технологический "тестовый стенд" это не совсем стандартное использование термина. Он все-таки скорее демонстрационный стенд, либо sample. Никаких "тестов" по факту на этом стенде не осуществляется
У нас исторически тестовый стенд был разработан под ручное функциональное тестирование. Демонстрация или примеры - это побочные его функции. Суть моего вопроса такая: бывает ли так, что для тестов в проекте используется что-то специально подготовленное, а не само приложение? Как устроено тестирование на проектах, где есть несколько реализаций под разных заказчиков?
Co-authored-by: Bratchikov Igor <bratchikov@neoplatform.ru>
| @@ -20,7 +20,7 @@ | |||
| * Фронтенд и бекенд находятся в одном репозитории | |||
| * Для запуска сервисов возможно использование docker | |||
| * Для выполнения интеграционных тестов необходима подготовленная база данных, содержащая как минимум все необходимые таблицы, а желательно еще и записи в таблицах справочников/реестров/полномочий | |||
| * Если PR/MR содержит скрипты изменения БД, они должны применяться на БД, создаваемую для тестов, перед запуском тестом | |||
| * Если PR/MR содержит скрипты изменения БД, они должны применяться на БД, создаваемую для тестов, перед запуском тестов | |||
There was a problem hiding this comment.
Не очень понятны условия. Зачем если? Тестируется не PR/MR, а ветка. Если в ветке есть скрипты (новее последнего снапшота базы), то применяем их.
There was a problem hiding this comment.
Не понял что предлагаешь изменить в тексте пункта. Вроде так и написано, как ты предлагаешь
There was a problem hiding this comment.
Скрипты, содержащиеся в тестируемой ветке, должны применяться на тестовую БД перед запуском тестов.
| 2. Касательно БД есть два варианта: | ||
| 1. **Без Docker**. На подготовленном сервере для интеграционного тестирования есть "эталонная" БД `etalon_db` с нужной схемой таблиц и нужными данными | ||
| 1. Командой `CREATE DATABASE %test_db_name% TEMPLATE etalon_db;` создается новая БД с именем, использующим какую-то уникальную для конкретного запуска тестов переменную, чтобы не произошло пересечений с параллельными запусками тестов | ||
| 2. На данную БД с помощью psql применяются скрипты, входящие в MR/PR. Если важен порядок применения скриптов, этот порядок должно быть можно обеспечить путем упорядочения файлов со скриптами по наименованию |
There was a problem hiding this comment.
Возможно, имеет смысл прописать формат наименования скриптов. Например:
YYYY-MM-DD-N <Описание скрипта>.sql
И снапшоты именовать также:
YYYY-MM-DD-N.backup
Применять только те скрипты, чья дата+номер позже последнего снапшота.
Время от времени делать новый снапшот, называть по дате+номеру последнего применённого скрипта.
There was a problem hiding this comment.
А что такое "снепшоты"? Я вроде в RFC не вводил такой термин, что имеется ввиду?
There was a problem hiding this comment.
Это бэкап БД на какой-то момент времени. etalon_db — это снапшот.
Может быть 2 подхода:
- Всегда создаём БД с нуля с помощью скриптов.
- Создаём БД из бэкапа и применяем только более новые скрипты. В этом случае нужно определить как часто обновлять бэкапы и как именовать бэкапы и скрипты, чтобы можно было определить какие скрипты новее последнего бэкапа.
| Описание подхода из данного RFC после реализации необходимо будет дополнить деталями относительно возможностей настройки пайплайна на конкретном проекте и опубликовать в виде статьи в документацию по платформе. | ||
|
|
||
| ## Недостатки | ||
| * Небходимо решить какой из вариантов создания тестовой БД использовать или реализовать пайплайны для обоих вариантов |
There was a problem hiding this comment.
Я за автономность. Имхо, тесты должны успешно выполняться на любой машине с интернетом, независимо от окружения.
There was a problem hiding this comment.
Не понял что предлагаешь. Сложно будет выполнить тесты на машине без докера и/или студии
There was a problem hiding this comment.
Я предлагаю прописать требования к тому, что должно быть на машине для запуска тестов.
| * После принятия PR/MR, содержащего скрипты изменения БД, для всех последующих запусков тестов должна создаваться БД, на которой эти скрипты уже применены | ||
| * Каждый интеграционный тест создает для себя в БД нужное состояние, однако БД общая для разных интеграционных тестов в рамках одного запуска. То есть, если на проекте активировано многопоточное исполнение тестов, код тестов должен предусматривать возможность наличия в БД данных, созданных соседними тестами, и это не должно приводить к падению тестов. После выполнения тест должен удалить из БД свои тестовые данные. | ||
| * Параллельно могут выполняться несколько запусков интеграционных тестов, у каждого запуска должна быть своя БД | ||
| * Если в тестовом запуске какие-то тесты упали, БД, созданная для этого тестового запуска, не должна удаляться автоматически, чтобы была возможность исследовать состояние, приведшее к падению (*хотя в данном случае гарантий все равно нет, потому что более поздний успешный тест может удалить и данные упавшего*) |
There was a problem hiding this comment.
Мне кажется, если тесты создают для себя структуры в БД - то этот пункт лишний, т.к. мы всегда можем по коммиту - воссоздать БД на момент выполнения теста
| * Интеграционные тесты должно быть можно просто запустить на локальной машине разработчика из IDE (возможно с использованием терминала) | ||
|
|
||
| ### Описание подхода | ||
| 1. Для выполнения интеграционного тестирования предлагается использовать отдельный тестовый стенд, а не пытаться запускать контейнеры на машине с агентом сборки. Это позволит уменьшить нагрузку на сервер сборки. Таким образом у прикладного проекта должен быть подготовленный "сервер", на котором будет осуществляться автоматизированное интеграционное тестирование |
There was a problem hiding this comment.
хелп gitlab'a пишет что это норм - https://docs.gitlab.com/ee/ci/services/
| 1. Командой `CREATE DATABASE %test_db_name% TEMPLATE etalon_db;` создается новая БД с именем, использующим какую-то уникальную для конкретного запуска тестов переменную, чтобы не произошло пересечений с параллельными запусками тестов | ||
| 2. На данную БД с помощью psql применяются скрипты, входящие в MR/PR. Если важен порядок применения скриптов, этот порядок должно быть можно обеспечить путем упорядочения файлов со скриптами по наименованию | ||
| 3. После принятия PR/MR со скриптами изменения БД запускается автоматический билд, применяющий данные скрипты на `etalon_db`, чтобы при новых запусках БД для тестов уже имела правильную схему и содержимое | ||
| 1. **С Docker**. Во внутреннем docker registry необходим образ PostgreSQL нужной версии с созданной БД для тестов `<internal_registry>/<project_name>/<test_db>:latest` |
There was a problem hiding this comment.
можно не "с соданной БД для тестов" а со скриптами создания такой БД, ванильные образы постгреса умеют выполнять sql\sh скрипты при старте, и в этих скриптах можно написать в т.ч. create database, pg_restore и т.д.
|
Всё круто, но у меня остался один вопрос. |
|
Запускаешь ту же БД что предполагается и в пайплайне, и на ней выполняешь тесты - оно работает, проверено. |
No description provided.