Go тестить, я создал! А что и зачем?

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

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

Когда нужно убедиться, что разные части системы корректно работают друг с другом, подключаются интеграционные тесты. Без базы данных, внешних сервисов или полноценной файловой системы здесь уже не обойтись. Но и тут Go остаётся лаконичным: через интерфейсы и подмену зависимостей можно легко реализовать моки и фейки с нулевой потерей в гибкости. А по необходимости доступна тестовая среда — локальный PostgreSQL, HTTP-сервер или контейнеры с нужными сервисами.

На верхнем уровне — end-to-end тесты, симулирующие поведение пользователя или внешнего клиента. При таких тестах вызывается публичный API и проверяется реакция системы на реальные события. Нужны они не всегда, но очень пригодятся, когда важна не только внутренняя логика, но и то, как выглядит система «снаружи».

Если нужно протестировать не только взаимодействие компонентов внутри приложения, но и между разными системами (сервисами, API, бекендами), пишутся межсистемные тесты, часто вынесенные в отдельный репозиторий. Они тяжелее, но зато при сложной архитектуре без них не обойтись.

Как писать читаемые и надёжные тесты

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

В Go читаемость важна тем более. Сам по себе язык очень лаконичен, поэтому всё, что выглядит чересчур громоздко, сразу выделяется. Поэтому разумно придерживаться проверенной структуры: Arrange → Act → Assert.

Пример:

func TestCreateOrderWithoutUserReturnsError(t *testing.T) {
    // Arrange
    service := NewOrderService(nil) // нет пользователя

    // Act
    err := service.CreateOrder(context.Background(), nil)

    // Assert
    require.Error(t, err, "ожидалась ошибка при создании заказа без пользователя")
}

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

Не ленитесь: называйте тесты своими именами. Функция TestSomething1 ничего не говорит. А вот TestCreateOrderWithoutUserReturnsError сразу объясняет суть. Писать такие названия — не прихоть, а проявление уважения к команде и будущему себе: вам обязательно захочется вернуться в прошлое и дать себе пинка за такие невразумительные имена, как asdfdfdf и qewrtew, которые лишь отнимают уйму времени.

Поддерживать простоту помогает и правильная организация тестов по файлам. Если у вас есть user.go, логично, чтобы тесты к нему находились в user_test.go. Разносить по тематике, а не сваливать всё в один общий файл — лучший способ сохранить порядок и сэкономить как своё, так и чужое время.

Тили-тили-тесты: разбираем типовые ошибки

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

Неправильное использование assert и requir

Эти методы из библиотеки testify выглядят похоже, но работают по-разному. Если assert позволяет тесту продолжаться даже при провале проверки, то require немедленно его останавливает. Важно понимать, когда использовать один, а когда другой.

// Плохо: если err != nil, то user может быть nil, что приведет к панике
assert.NoError(t, err)
assert.Equal(t, "admin", user.Name) // может паниковать, если user == nil

// Лучше: прерываем тест при критической ошибке
require.NoError(t, err, "failed to get user")
assert.Equal(t, "admin", user.Name)

Игнорирование ошибок в примерах

// Плохо: игнорирование ошибок в одних только тестах уже создаёт плохой пример
// и может скрыть реальные проблемы
func TestCreateUserBadErrorHandling(t *testing.T) {
    db, mock, _ := sqlmock.New() // что если произошла ошибка при создании мока?
    defer db.Close()
    
    repo := NewUserRepo(db)
    mock.ExpectExec("INSERT INTO users").
        WithArgs("bob@example.com").
        WillReturnResult(sqlmock.NewResult(1, 1))

    _ = repo.CreateUser(context.Background(), "bob@example.com") // игнорируем результат!
    _ = mock.ExpectationsWereMet() // игнорируем проверку ожиданий!
}

// Хорошо: корректная обработка всех ошибок
func TestCreateUserProperErrorHandling(t *testing.T) {
    db, mock, err := sqlmock.New()
    require.NoError(t, err, "failed to create SQL mock") // проверяем создание мока
    defer db.Close()

    repo := NewUserRepo(db)
    mock.ExpectExec("INSERT INTO users").
        WithArgs("bob@example.com").
        WillReturnResult(sqlmock.NewResult(1, 1))

    err = repo.CreateUser(context.Background(), "bob@example.com")
    require.NoError(t, err, "failed to create user") // проверяем результат операции
    
    err = mock.ExpectationsWereMet()
    require.NoError(t, err, "SQL mock expectations were not met") // проверяем выполнение ожиданий
}

Почему это важно:

1. Игнорирование ошибок в тестах кроет в себе опасность сокрытия реальных проблем в их настройке.

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

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

Сравнение сложных структур вручную

Если структура вложенная, а вы сравниваете поля по одному, легко что-то упустить. Вместо этого лучше использовать современные инструменты:

func TestCreateUser_ReturnsCorrectUser(t *testing.T) {
    expected := User{
        Name: "Alice",
        Email: "alice@example.com",
        Role: Role{Title: "admin", Level: 1},
    }

    actual, err := service.CreateUser(ctx, "alice@example.com")
    require.NoError(t, err)

    // Используем cmp.Diff для наглядного сравнения
    if diff := cmp.Diff(expected, actual); diff != "" {
        t.Errorf("user mismatch (-want +got):\n%s", diff)
    }
    
    // Или testify для простых случаев
    assert.Equal(t, expected, actual)
}

Тесты без объяснения логики

// Плохо: непонятно, почему это должно быть ложью
assert.False(t, Validate("admin1"))

// Лучше: объясняем ожидание
assert.False(t, Validate("admin1"), 
    "usernames with digits should be invalid")

Как работать с зависимостями: stub, mock, fake

Реальный код редко существует в вакууме. Он зависит от базы данных, сетевых вызовов и внешних API. Но если тестировать всё это «вживую», приходится тратить уйму времени, а сами тесты становятся нестабильными и трудновоспроизводимыми. Чтобы избежать этого, подменяют зависимости. В Go для этого почти всегда используют интерфейсы: благодаря встроенной системе типов можно легко заменить «настоящий» компонент на управляемый.

Стаб (stub)

Стаб — это простая заглушка, которая всегда возвращает фиксированный результат. Её цель — предсказуемость.

Когда пригодится: если нужно проверить реакцию на определённый ответ или ошибку.

type EmailSender interface {
    Send(ctx context.Context, to, subject, body string) error
}

type StubEmailSender struct {
    ShouldFail bool
}

func (s *StubEmailSender) Send(ctx context.Context, to, subject, body string) error {
    if s.ShouldFail {
        return errors.New("failed to send email")
    }
    return nil // всегда успешно
}

В тесте:

func TestCreateUser_HandlesEmailFailure(t *testing.T) {
    sender := &StubEmailSender{ShouldFail: true}
    service := NewUserService(sender)

    err := service.CreateUser(context.Background(), "alice@example.com")
    
    // Проверяем, что сервис правильно обрабатывает ошибку отправки
    require.Error(t, err)
    assert.Contains(t, err.Error(), "failed to send email")
}

Мок (mock)

Мок — подмена, которая не только возвращает результат, но и запоминает вызовы: какие параметры и сколько раз.

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

С использованием testify/mock:

import "github.com/stretchr/testify/mock"

type MockEmailSender struct {
    mock.Mock
}

func (m *MockEmailSender) Send(ctx context.Context, to, subject, body string) error {
    args := m.Called(ctx, to, subject, body)
    return args.Error(0)
}

В тесте:

func TestCreateUser_SendsWelcomeEmail(t *testing.T) {
    mockSender := new(MockEmailSender)
    mockSender.On("Send", 
        mock.AnythingOfType("*context.emptyCtx"),
        "alice@example.com", 
        "Welcome", 
        mock.AnythingOfType("string")).Return(nil)

    service := NewUserService(mockSender)
    err := service.CreateUser(context.Background(), "alice@example.com")

    require.NoError(t, err)
    mockSender.AssertExpectations(t)
}

Фейк (fake)

Фейк — это реализация, которая работает «по-настоящему», но упрощённо. Например, фейковая база хранит данные в map.

Когда пригодится: если хочется имитировать настоящую работу компонента, не задействуя стороннюю инфраструктуру.

type FakeEmailSender struct {
    SentMessages []EmailMessage
    mu          sync.RWMutex
}

type EmailMessage struct {
    To      string
    Subject string
    Body    string
}

func (f *FakeEmailSender) Send(ctx context.Context, to, subject, body string) error {
    f.mu.Lock()
    defer f.mu.Unlock()
    
    f.SentMessages = append(f.SentMessages, EmailMessage{
        To:      to,
        Subject: subject,
        Body:    body,
    })
    return nil
}

func (f *FakeEmailSender) GetSentMessages() []EmailMessage {
    f.mu.RLock()
    defer f.mu.RUnlock()
    
    // Возвращаем копию для безопасности
    messages := make([]EmailMessage, len(f.SentMessages))
    copy(messages, f.SentMessages)
    return messages
}

В тесте:

func TestCreateUser_EmailContent(t *testing.T) {
    fakeSender := &FakeEmailSender{}
    service := NewUserService(fakeSender)

    err := service.CreateUser(context.Background(), "bob@example.com")
    require.NoError(t, err)

    messages := fakeSender.GetSentMessages()
    require.Len(t, messages, 1)
    
    assert.Equal(t, "bob@example.com", messages[0].To)
    assert.Contains(t, messages[0].Subject, "Welcome")
}

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

Заключение

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

В языке Go автотесты вплетены в саму ткань разработки. Они не требуют громоздких инструментов, лишних зависимостей или сложной настройки. Понятный синтаксис, быстрая сборка, встроенная параллельность: всё доступно прямо из коробки.

За годы развития экосистемы Go выработались эффективные практики тестирования:

• Dependency injection через интерфейсы стал основой тестируемого кода, позволяющей легко подменять реальные компоненты на stubs, mocks и fakes, а контекст-ориентированный дизайн с правильной обработкой отмен и таймаутов обеспечивает максимальную надёжность и предсказуемость.

• Структура Arrange-Act-Assert помогает писать читаемые тесты, а табличные тесты с t.Run() делают их масштабируемыми. Тесты не упадут, если правильно использовать assert и require из библиотеки testify, а при помощи таких современных инструментов, как cmp.Diff, сравнение сложных структур данных становится в разы проще.

• Работа с базами данных в тестах требует особого подхода. Транзакции с откатом обеспечивают изоляцию, SQL-моки позволяют тестировать бизнес-логику при отсутствии реальной базы, а testcontainers дают возможность запускать полноценные интеграционные тесты. Комбинируя эти подходы, можно добиться максимальной эффективности.

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

Хорошие тесты — это инвестиция в будущее. Каждый написанный тест делает проект чуть стабильнее, команду увереннее, а релизы — предсказуемыми. С ними вы обретаете возможность двигаться быстрее завтра за счёт качественной работы сегодня. Если задача кажется непосильной, а от объёма требуемой работы спирает дыхание, начните с малого: напишите первый unit-тест для новой функции. Добавьте интерфейс вместо прямого вызова внешнего сервиса. Настройте автоматический запуск тестов при каждом коммите.

И постепенно, тест за тестом, вы построите надёжную защиту своего кода. Будьте уверены: будущий вы скажет себе это за это спасибо!