Фикстуры в 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 и вынести управление инфраструктурой за пределы тестового сценария.

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

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

推荐订阅源