Создаём инфраструктуру для интеграционных тестов: делаем образы и подводим итоги
Привет! Это вторая и (пока что) последняя статья из цикла про создание инфраструктуры интеграционных тестов. Первая была здесь.
В прошлый раз мы выяснили:
зачем команда Fiji из 2ГИС решила переизобрести инфраструктуру интеграционных тестов;
какие вообще бывают окружения для автотестов, и в каких случаях их применять;
какое решение мы выбрали и почему;
как мы использовали ресурсы K8s и взаимодействовали с ними из кода.
Стек команды Fiji — C#, NUnit. Непрерывную интеграцию делаем на TeamCity, отчёты по автотестам смотрим в Allure. Базы данных для интеграционных тестов поднимаем в Docker-контейнерах внутри Kubernetes.
В этой части статьи — подготовка образов тестовой базы данных. Будет много Докера и практики. К чёрту предисловия, погнали!
Готовим образ тестовой базы данных в Docker
Сборка образа напоминает лабораторную работу в универе: берёшь чей-то готовый вариант и докручиваешь под свои нужды.
В мире Докера основной банк таких вариантов — докерхаб. Лезем туда и качаем базовый образ. Возможно, в будущем сделаем ему наследников. Если планируете всерьёз собирать образы и делиться ими, подумайте о развертывании docker registry внутри корпоративной сети.
На докерхабе есть официальные образы и неофициальные. Правило одно — не берите вслепую. Изучите докерфайл — что происходило с системой до вас. Проверьте настройки внутри образа. У меня был случай, когда в контейнере неверно отображались арабские символы — нужно было поиграть с настройками сервера.
Когда почувствуете себя в контейнере как дома, начнётся самая интересная задача. У вас на руках базовый образ и большая мечта про тестовые данные в Докере. Надо понять, как одно превратить в другое.
Сегодня обсудим, какие варианты для этого есть. Важно помнить, что универсального рецепта нет — выберите решение под себя или придумайте свой собственный способ.
Рассуждаем, какие бывают образы БД для интеграционных тестов
Нехитрые рассуждения приводят нас к четырём основным стратегиям подготовки образа для тестовой базы данных. Разберём каждую из них.
1. Не делаем образы
Берём уже готовый образ и работаем с ним
При поднятии контейнера нужно будет сконфигурировать внутри образа переменные среды и прочие настройки. Вы будете создавать схему данных из кода, а потом ещё наполнять данными. И делать это каждый раз при запуске тестов.
Этот способ хорошо подойдёт, если:
2. Образ без данных
Берём образ, настраиваем всё, кроме тестовых данных — и вперёд
Берём базовый образ. Конфигурируем настройки, подкладываем необходимые плагины, накатываем схему данных. Создаем новый образ с готовой к работе базой данных, в которой пока нет тестовых данных. Будем создавать их из кода.
Этот способ подойдёт, если:
при запуске тестов вы не хотите готовить окружение — только создавать тестовые данные;
вам не нужно создавать специфические и сложно связанные тестовые данные.
3. Образ с реальными данными
Берём образ и копируем внутрь реальные данные
А если просто взять нашу боевую базу данных и засунуть её внутрь образа? Когда он устареет, просто сделаем всё заново. Да, в нём будут лишние данные, но зато всё под рукой.
Можно исхитриться и засунуть в образ только часть реальных данных. Другой вопрос — как отделить эту самую часть, не потеряв в целостности данных? Например, для нас вырезать с карты отдельный город — очень сложная задача, слишком уж много взаимосвязей.
Способ подойдёт, если:
у вас очень компактная база и не нужно хранить много тегов;
ваши тесты имеют смысл именно с реальными данными;
в боевой базе данных нет конфиденциальных данных или вы готовы их маскировать;
вы можете аккуратно вырезать кусок данных и будете в нём уверены.
Размер нашей БД с картографическими данными — несколько терабайт. Представим, что случайная машина в кластере K8s пытается скачать такой объём. Получится не быстро
