Фикстуры в 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 и вынести управление инфраструктурой за пределы тестового сценария.
На небольших примерах разница может казаться несущественной. Но в реальных проектах с сотнями или тысячами интеграционных тестов централизованный жизненный цикл ресурсов быстро начинает экономить время: код становится короче, тесты — читаемее, а изменения инфраструктуры — предсказуемыми и локальными.
Фикстуры не делают тесты «магическими» — они просто возвращают им основное назначение: проверку поведения, а не управление окружением.