NikitaFilonov
Разработка

Фикстуры в Go: как перестать писать инфраструктуру в автотестах

Фикстуры в Go: как перестать писать инфраструктуру в автотестах

В Go нет фикстур, и в интеграционных тестах это быстро превращается в копипаст. Разбираем, как вынести инфраструктуру из автотестов и управлять жизненным циклом ресурсов.

Вступление

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

На практике это приводит к дублированию кода и копипасте. Всё, что должно жить в инфраструктурном слое, оказывается прямо внутри тестов. Нужно открыть соединение с базой — это делается в тесте. Нужно его закрыть — тоже в тесте. Подготовка данных, инициализация клиентов, очистка состояния — всё смешивается с логикой проверки.

В этой статье разберёмся, как можно внедрить фикстуры в Go-автотесты аккуратно и без лишней магии — в духе того, как это сделано в pytest или JUnit. В качестве примера будем использовать Axiom.

Что обычно называют фикстурой

В тестовых фреймворках фикстура — это не просто вспомогательная функция. Это ресурс с управляемым жизненным циклом, который создаётся и уничтожается вне тестового сценария.

Обычно фикстура обладает несколькими свойствами:

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

Фикстура отвечает за инфраструктуру: соединения с базами, клиентов сервисов, подготовку окружения и тестовых данных. Тест при этом работает уже с готовыми зависимостями и описывает только проверяемое поведение.

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

Пример без фикстур

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

Представим простой сценарий: нужно инициализировать клиент для работы с пользователями, создать пользователя, выполнить проверку и после теста гарантированно удалить созданные данные. Классический жизненный цикл сущности в интеграционном тесте.

func TestGetUser(t *testing.T) { // Инициализация клиента client, err := NewUserClient() if err != nil { t.Fatalf("failed to create client: %v", err) } defer client.Close() // Подготовка тестовых данных user, err := CreateUser(client) if err != nil { t.Fatalf("failed to create user: %v", err) } defer func() { _ = DeleteUser(client, user.ID) }() // Вызов тестируемого поведения resp, err := client.GetUser(user.ID) if err != nil { t.Fatalf("failed to get user: %v", err) } // Проверка результата if resp.ID != user.ID { t.Fatalf("unexpected user id") } }

На первый взгляд код выглядит безобидно. Всё явно, всё под контролем, ничего «магического». Но инфраструктурная логика уже полностью живёт внутри теста: инициализация клиента, управление соединениями, подготовка данных и cleanup.

Теперь представьте, что:

  • тест становится в 3–4 раза больше,
  • появляется несколько клиентов и зависимостей,
  • добавляется условный cleanup,
  • а таких тестов — сотни или тысячи, как это обычно бывает в продакшене.

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

Именно эту проблему и призваны решать фикстуры.

Пример с фикстурами

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

Один из способов добавить инфраструктурный слой в Go-тесты — использовать фикстуры из Axiom. В Axiom фикстура — это лениво вычисляемый ресурс с управляемым жизненным циклом: она создаётся при первом обращении, кешируется на время выполнения теста и автоматически очищается после завершения теста. При повторных попытках (retry) жизненный цикл фикстур начинается заново.

Ниже — полный пример: фикстура клиента, фикстура пользователя (зависящая от клиента) и сам тест.

package user_test import ( "testing" "github.com/Nikita-Filonov/axiom" ) // ----------------------------------------------------------------------------- // Fixtures // ----------------------------------------------------------------------------- // UserClientFixture — фикстура клиента. // Создаётся при первом обращении и автоматически закрывается после теста. func UserClientFixture(_ *axiom.Config) (any, func(), error) { client, err := NewUserClient() if err != nil { return nil, nil, err } cleanup := func() { client.Close() } return client, cleanup, nil } // UserFixture — фикстура пользователя. // Декларативно зависит от фикстуры клиента. func UserFixture(cfg *axiom.Config) (any, func(), error) { client := axiom.GetFixture[*UserClient](cfg, "client") user, err := client.CreateUser(client) if err != nil { return nil, nil, err } cleanup := func() { _ = client.DeleteUser(client, user.ID) } return user, cleanup, nil } // ----------------------------------------------------------------------------- // Runner // ----------------------------------------------------------------------------- var runner = axiom.NewRunner( // Глобальная фикстура клиента axiom.WithRunnerFixture("client", UserClientFixture), ) // ----------------------------------------------------------------------------- // Test // ----------------------------------------------------------------------------- func TestGetUser(t *testing.T) { // Описываем Case (обязателен для Runner) c := axiom.NewCase( axiom.WithCaseName("get user by id"), // Локальная фикстура пользователя axiom.WithCaseFixture("user", UserFixture), ) runner.RunCase(t, c, func(cfg *axiom.Config) { // Получаем готовые зависимости client := axiom.GetFixture[*UserClient](cfg, "client") user := axiom.GetFixture[*User](cfg, "user") // Проверяем бизнес-поведение resp, err := client.GetUser(user.ID) if err != nil { t.Fatalf("failed to get user: %v", err) } if resp.ID != user.ID { t.Fatalf("unexpected user id") } }) }

Что здесь принципиально важно:

  • фикстура клиента отвечает только за создание и закрытие клиента;
  • фикстура пользователя декларативно зависит от клиента;
  • создание и удаление пользователя вынесены из теста;
  • Runner управляет инфраструктурой, Case — конкретным сценарием;
  • тест работает только с готовыми зависимостями и проверяет поведение.

Фикстуры создаются лениво при первом обращении через GetFixture, автоматически переиспользуются внутри теста и гарантированно очищаются после его завершения. При retry весь жизненный цикл фикстур будет выполнен заново, без протекания состояния между попытками.

Заключение

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

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

Фикстуры не делают тесты «магическими» — они просто возвращают им основное назначение: проверку поведения, а не управление окружением.