Привет! Я инженер по автоматизации тестирования. Уже несколько лет я создаю и сопровождаю QA-процессы в реальных проектах - от ручных проверок до автоматизации с CI/CD-интеграций.
В работе я чаще занимаюсь фронтовыми автотестами, но мне захотелось глубже разобраться и поделиться API-автотестированием и полностью пройти путь - от кода приложенния до запуска тестов в пайплайне.
Так появился мой pet-проект, который вы можете найти на GitHub:
👉 github.com/annalya-github/testProjBackendAutotestsCICD
🚀 Шаг 1. Создаём простой backend
Я начала с самого простого - создала Spring Boot проект, в котором реализовала CRUD-операции: добавить карточку, прочитать, обновить и удалить.
Можно представить это как небольшую библиотеку карточек:
- сначала мы создаём карточку (добавляем запись);
- потом можем открыть и почитать её;
- обновить, добавив свои комментарии;
- или удалить, если больше не нужно.
Так я постепенно построила базовую структуру проекта:
- Card - модель данных (у каждой карточки есть id, название и описание);
- CardRepository - интерфейс на основе JpaRepository, который даёт стандартные методы для работы с БД;
- CardController - контроллер, который обрабатывает HTTP-запросы при помощи Spring Web.
После сборки я просто запустила класс TestProjApplication и открыла http://localhost:8080/cards в браузере.
Там отображался пустой список карточек. Через терминал я отправила POST-запрос, и в списке появилась новая карточка ✅
Это значит, что API работает!
🧪 Шаг 2. Пишем API-автотесты с RestAssured
Следующим шагом я создала отдельный модуль с API-тестами, чтобы не смешивать их с основным приложением.
Здесь я использовала библиотеку RestAssured - с её помощью можно отправлять запросы к серверу (например, получить список карточек, создать новую или удалить существующую) и сразу проверять, что ответы приходят правильные.
Сначала я написала самый простой тест - проверить, что мой сервер вообще отвечает и возвращает данные.
Когда я запустила его впервые, тест упал - потому что backend ещё не был запущен 😅
После того как я сделала run backend проекта и повторила запуск автотестов, тест прошёл успешно 🎉
Это был первый рабочий результат - мой мини-сервис реально обрабатывал запросы, а автотесты подтверждали, что API работает как нужно.
🐳 Шаг 3. Подключаем Docker
Когда проект состоит из нескольких частей - например, есть бэкенд, база данных и API-тесты, - всё это нужно запускать в определённом порядке и в нужной среде.
Если делать это вручную, легко запутаться: у кого-то Java 17, у кого-то 21, кто-то забыл запустить сервер - и тесты падают.
💡 Docker решает эту проблему.
Он позволяет «упаковать» всё, что нужно приложению, в контейнер - как в мини-компьютер, где уже есть правильная версия Java, зависимости и настройки.
🔹 Как это работает на практике
1️⃣ Dockerfile - это инструкция, как собрать контейнер.
В нём мы описываем:
– из какого окружения начинаем (например, java:21),
– какие команды нужно выполнить (собрать проект, установить зависимости),
– что запустить при старте.
👉 В результате получается image - готовый «слепок» приложения.
2️⃣ Когда мы запускаем образ, создаётся container - то есть живая копия приложения, которая работает изолированно.
Например: у меня запущен контейнер backend, внутри которого Spring Boot-приложение доступно по http://localhost:8080.
3️⃣ Чтобы не запускать всё вручную, используется docker-compose.
Это файл, где можно описать сразу несколько сервисов и как они связаны между собой.
Например:
– сначала поднимаем backend,
–ждём, пока он ответит status: UP,
–потом запускаем контейнер api-tests, который обращается к backend по адресу http://backend:8080.
4️⃣ Теперь вместо десятков ручных шагов достаточно одной команды: docker compose -f docker-compose.ci.yml up --build
После этого:
✅ Собирается Docker-образ бэкенда
✅ Запускается сервер
✅ Выполняются API-тесты
✅ Всё автоматически останавливается после завершения
Раньше я запускала сервер вручную, потом отдельно тесты.
Теперь всё упаковано в Docker - я нажимаю одну команду, и проект полностью поднимается, проверяется и сворачивается.
Это первый шаг к настоящему автоматизированному пайплайну CI/CD 🚀
🔄 Шаг 4. Интеграция в CI/CD
Чтобы тесты запускались автоматически при каждом пуше в main, я добавила workflow для GitHub Actions.
Он выполняет:
- 🧱 Сборку Docker-образов для backend и тестов
- 🚀 Запуск backend-контейнера и ожидание статуса "UP"
- 🧪 Запуск API-тестов внутри контейнера
- 📊 Сохранение отчётов Allure
- 🧹 Остановку контейнеров и очистку окружения
Так CI/CD-пайплайн проходит полный цикл: build → test → report → cleanup,
и всё это - без ручных действий, прямо в GitHub.
🌟 Зачем я сделала этот проект
✅ Хотела глубже понять, как строится тестирование API на практике
✅ Научиться работать с Docker и GitHub Actions
✅ Получить готовый шаблон для pet-проектов и демонстрации CI/CD
✅ И просто - объединить в одном проекте backend, тесты и DevOps-инфраструктуру
💬 Контакты
Буду рада, если вы добавитесь в LinkedIn - открыта к новым профессиональным знакомствам и интересным предложениям в сфере QA и автоматизации.
🔗 LinkedIn: linkedin.com/in/anna-lyashutina
✨ Спасибо, что дочитали! Если вам интересна тема тестирования и Автоматизации CI/CD - подписывайтесь, в следующих статьях расскажу, как добавить UI-часть и Allure-отчёты.