Stepik / Никита Филонов - Автоматизация тестирования API с Go

Вы освоите HTTP, gRPC, Resty, Protobuf, Axiom, Allure, Testify, gofakeit и CI/CD. Научитесь строить полноценную инфраструктуру API-автотестов на Go, проектировать поддерживаемую архитектуру, настраивать параллельный запуск и отчётность, применять лучшие практики и работать с реальными сценариями. В финале соберёте готовый проект — от первых API-запросов до полноценного тестового фреймворка.

Полноценная система API-автотестов на Go:

Написать несколько HTTP- или gRPC-тестов на Go несложно. Для этого достаточно Resty, Protobuf, Testify и стандартного пакета testing.

Проблемы начинаются тогда, когда тестов становится не десять, а несколько сотен.

В этот момент простые примеры перестают масштабироваться. Тесты начинают дублировать друг друга, подготовка данных занимает больше места, чем сам сценарий, API-клиенты смешиваются с бизнес-логикой, параллельный запуск ломает состояние, а диагностика падений превращается в отдельное расследование.

Ни Resty, ни Testify, ни Protobuf сами по себе не решают эти задачи. Это инструменты, а не архитектура.

В этом курсе вы не просто напишете набор API-тестов. Вы последовательно построите полноценную инфраструктуру HTTP- и gRPC-автотестов на Go и разберётесь, как сделать её:

независимой

читаемой

переиспользуемой

удобной для диагностики

безопасной для параллельного запуска

готовой к развитию вместе с проектом

Главная цель курса:

Курс формирует комплексную и фундаментальную базу для проектирования API-автотестов на Go.

Мы начнём с устройства API, клиент-серверного взаимодействия, HTTP и gRPC. Затем напишем первые тесты с использованием стандартного пакета testing, Resty, Protobuf и Testify. После этого будем постепенно развивать проект: отделять транспортный слой, создавать API-клиенты, управлять тестовыми данными, проектировать фикстуры и проверки, подключать отчётность, логирование, параллельный запуск и CI/CD.

Главный результат — понимание всей системы автоматизации: от отправки запроса до архитектуры проекта, жизненного цикла тестовых данных, диагностики ошибок и организации больших тестовых наборов.

Инструменты занимают важное место в программе, но основной фокус сделан на инженерных принципах, которые сохраняют ценность независимо от конкретной библиотеки:

разделение ответственности между слоями

изоляция тестовых сценариев от инфраструктуры

управление зависимостями и состоянием

подготовка и очистка тестовых данных

проектирование переиспользуемых клиентов

создание доменных проверок

организация параллельного выполнения

логирование и диагностика падений

масштабирование проекта вместе с ростом количества тестов

Почему автоматизация тестирования на Go требует отдельного подхода:

В Go нет единственного общепринятого стека, который полностью решает задачи большого проекта автотестов.

Стандартный пакет testing предоставляет надёжную и предсказуемую основу, но оставляет разработчику большую часть инфраструктурных решений.

Testify дополняет стандартную библиотеку удобными проверками и тестовыми наборами, однако самостоятельно не решает вопросы архитектуры проекта, управления зависимостями, метаданных, плагинов, отчётности и организации сложного параллельного запуска.

Ginkgo предлагает полноценный BDD-подход и собственный DSL, добавляя дополнительный уровень абстракции, который подходит одним командам и не соответствует требованиям других.

Поэтому тестовая инфраструктура в Go редко возникает из простого объединения нескольких библиотек. Её приходится осознанно проектировать: определять границы компонентов, жизненный цикл зависимостей, правила подготовки данных, структуру тестов и механизм их выполнения.

Многие команды годами выращивают такую инфраструктуру самостоятельно или переносят решения из Java, Python и других языков. Часть этих подходов полезна, но некоторые из них плохо сочетаются с простотой и явностью, которые приняты в экосистеме Go.

В курсе мы разберём эти особенности и построим архитектуру, которая остаётся понятной, расширяемой и естественной для Go-проекта.

Три с половиной года практики, собранные в одном курсе:

В основе курса лежат три с половиной года интенсивной работы с API-, интеграционными и изоляционными автотестами на Go.

За это время я создавал и поддерживал тестовую инфраструктуру, наблюдал за её развитием вместе с продуктами, внедрял решения в разных командах, сталкивался с ограничениями существующих инструментов и неоднократно пересматривал неудачные архитектурные подходы.

На практике мне приходилось решать ситуации, когда:

тесты невозможно безопасно запускать параллельно

подготовка данных становится сложнее самого сценария

фикстуры превращаются в набор несвязанных функций

инфраструктурный код копируется между десятками тестов

API-клиенты смешивают транспорт, модели и бизнес-логику

логирование и отчётность подключаются вручную

повторные запуски скрывают реальные причины нестабильности

тесты работают локально, но регулярно падают в CI

архитектура становится настолько сложной, что команда боится её изменять

Эти проблемы не были придуманы специально для учебных примеров. Они возникали при развитии настоящих тестовых проектов. Работа над их решением в конечном итоге привела к созданию Axiom.

Материал про Axiom из первых рук:

Я являюсь автором Axiom и знаю не только его публичный API, но и причины, стоящие за каждым архитектурным решением.

В курсе разбирается опыт, который невозможно получить из одного README или набора примеров:

какие подходы рассматривались на ранних этапах

от каких решений пришлось отказаться

какие проблемы проявились только при росте количества тестов

что пришлось переписывать после внедрения

как различные механизмы работают при параллельном запуске

как фреймворк ведёт себя на больших тестовых наборах

какие компромиссы приходится учитывать при проектировании инфраструктуры

Resty, Testify, Protobuf и Allure можно изучать отдельно по документации. В этом курсе они объединяются в одну систему вместе с архитектурой, тестовыми данными, клиентами, фикстурами, проверками, отчётностью и CI/CD.

По сочетанию авторского фреймворка, материала от его создателя и последовательного построения полноценной инфраструктуры курс не имеет прямых аналогов.

При этом программа не строится исключительно вокруг Axiom. Фреймворк помогает реализовать универсальные концепции, которые применимы и при проектировании собственной инфраструктуры:

управление жизненным циклом тестов

композиция зависимостей

разделение сценариев и технического кода

переиспользование компонентов

организация метаданных

расширение через плагины

безопасное параллельное в