4. Testability и дизайн кода

Testability и дизайн кода

"Простота и надежность — это не те качества, которые можно добавить в программу задним числом, словно глазурь на готовый торт. Если архитектура модуля порочна изначально, никакой тестовый фреймворк в мире не сделает его надежным."
— Брайан Керниган

Если вы когда-либо открывали функцию в Go-проекте и ловили себя на мысли: «Я понятия не имею, как написать на это тест, не подняв при этом половину облачной инфраструктуры», — знайте: проблема кроется вовсе не в ваших навыках тестирования. Проблема кроется в архитектурном дизайне самого кода.

Тестируемость (Testability) — это не случайный побочный эффект хорошей архитектуры. Это ее фундаментальный движок. Программа, которую легко и приятно тестировать, по определению обладает слабой связностью компонентов (Loose Coupling), высокой функциональной когезией (High Cohesion) и прозрачным, детерминированным управлением состоянием.

В языке Go, где создатели сознательно отказались от тяжелых динамических контейнеров инверсии управления (IoC/DI) на базе рефлексии (привычных по мирам Java Spring и .NET), дизайн, ориентированный на тестируемость, становится вопросом физического выживания кодовой базы.

Корень зла: Неявные зависимости и Глобальное состояние

Самый верный способ превратить тестирование бэкенда на Go в мучение — использовать неконтролируемое глобальное состояние и зашитые намертво зависимости (Hardcoded Dependencies).

Взгляните на хрестоматийный пример плохого кода:

package user

import (
    "database/sql"
    "time"

    // Антипаттерн: импорт драйвера БД ради побочного эффекта init() внутри пакета домена
    _ "github.com/lib/pq"
)

var db *sql.DB // Глобальное мутабельное состояние пакета!

func init() {
    var err error
    // Неконтролируемый I/O и сетевой вызов при загрузке бинарника
    db, err = sql.Open("postgres", "postgres://user:pass@localhost:5432/db?sslmode=disable")
    if err != nil {
        panic(err)
    }
}

func CreateUser(username string) error {
    createdAt := time.Now() // Неявная скрытая зависимость от физических часов ОС!
    _, err := db.Exec("INSERT INTO users (username, created_at) VALUES ($1, $2)", username, createdAt)
    return err
}

Почему этот код принципиально невозможно протестировать в чистом изолированном окружении?

1. Катастрофа изоляции: Как только любой тестовый файл в вашем проекте импортирует пакет user, рантайм Go немедленно вызывает функцию init(). Пакет пытается подключиться к несуществующей локальной СУБД, и тесты падают с фатальной ошибкой connection refused еще до выполнения первой строки тестового сценария.
2. Отсутствие архитектурных швов (Seams): Переменная db инкапсулирована внутри пакета и намертво привязана к глобальному указателю *sql.DB. Вы не можете подменить ее на тестовую заглушку или мок без грязных хаков.
3. Недетерминированность во времени: Функция жестко вызывает системную функцию time.Now(). Вы не можете написать точный assert, проверяющий ожидаемое значение времени в записи базы данных, потому что каждый запуск выдает уникальный наносекундный таймстамп.

Внедрение зависимостей (Dependency Injection) в стиле Go

В философии Go внедрение зависимостей (DI) реализуется без сложной рефлексии и аннотаций: через явные конструкторы и структуры. Это делает поток данных прозрачным для компилятора, линтера и самого разработчика.

Сделаем первый шаг к исправлению нашего сервиса:

package user

import (
    "context"
    "database/sql"
    "time"
)

// Service явно инкапсулирует необходимые для работы зависимости
type Service struct {
    db *sql.DB
}

// NewService — явный конструктор, принимающий зависимости извне
func NewService(db *sql.DB) *Service {
    return &Service{
        db: db,
    }
}

// CreateUser принимает явный контекст и детерминированное время создания
func (s *Service) CreateUser(ctx context.Context, username string, createdAt time.Time) error {
    const query = "INSERT INTO users (username, created_at) VALUES ($1, $2)"
    _, err := s.db.ExecContext(ctx, query, username, createdAt)
    return err
}

Мы избавились от скрытого состояния: зависимость от *sql.DB стала явной, а системное время time.Now() больше не генерируется под ковром. Однако сервис всё еще жестко привязан к конкретному типу СУБД — реляционному пулу *sql.DB. Чтобы написать быстрый Unit-тест без поднятия PostgreSQL, нам нужен следующий шаг абстракции.

Интерфейсы: Главный инструмент Testability

Главная суперсила языка Go — неявное удовлетворение интерфейсов (Implicit Interface Satisfaction). В отличие от C++, C# или Java, типу в Go не нужно объявлять ключевое слово implements MyInterface. Если методы структуры совпадают по сигнатуре с методами интерфейса — структура автоматически реализует данный контракт.

Это порождает ключевой архитектурный принцип Go:
Интерфейсы должны определяться там, где они потребляются (Consumer), а не там, где они реализуются (Producer).

Вместо создания гигантского глобального интерфейса базы данных, наш бизнес-слой Service декларирует свой собственный минималистичный контракт:

package user

import (
    "context"
    "time"
)

// UserRepository объявляет только те методы, которые реально нужны данному сервису
type UserRepository interface {
    InsertUser(ctx context.Context, username string, createdAt time.Time) error
}

type Service struct {
    repo UserRepository
}

func NewService(repo UserRepository) *Service {
    return &Service{repo: repo}
}

func (s *Service) CreateUser(ctx context.Context, username string, createdAt time.Time) error {
    // Доменная валидация
    if username == "" {
        return ErrEmptyUsername
    }
    return s.repo.InsertUser(ctx, username, createdAt)
}

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

package user_test

import (
    "context"
    "errors"
    "testing"
    "time"

    "myapp/user"
)

// MockRepo — легковесный мок, реализующий интерфейс user.UserRepository
type MockRepo struct {
    InsertedUsername  string
    InsertedCreatedAt time.Time
    ErrToReturn       error
}

func (m *MockRepo) InsertUser(ctx context.Context, username string, createdAt time.Time) error {
    m.InsertedUsername = username
    m.InsertedCreatedAt = createdAt
    return m.ErrToReturn
}

func TestService_CreateUser(t *testing.T) {
    mock := &MockRepo{ErrToReturn: nil}
    svc := user.NewService(mock)

    fixedTime := time.Date(2026, 5, 1, 12, 0, 0, 0, time.UTC)
    err := svc.CreateUser(context.Background(), "alice", fixedTime)

    if err != nil {
        t.Fatalf("expected no error, got %v", err)
    }
    if mock.InsertedUsername != "alice" {
        t.Errorf("expected username 'alice', got '%s'", mock.InsertedUsername)
    }
    if !mock.InsertedCreatedAt.Equal(fixedTime) {
        t.Errorf("expected timestamp %v, got %v", fixedTime, mock.InsertedCreatedAt)
    }
}

flowchart TD
    subgraph Tight["Слабая тестируемость (Жесткое сцепление)"]
        S1["user.Service"] -->|"Прямая зависимость от конкретного типа"| DB1["*sql.DB (PostgreSQL)"]
    end

    subgraph Decoupled["Высокая тестируемость (Инверсия зависимостей)"]
        S2["user.Service"] -->|"Зависит от локального контракта"| I["UserRepository<br>(Consumer Interface)"]
        DB2["postgres.Repository"] -.->|"Неявно реализует"| I
        Mock["MockRepo (Тестовая заглушка)"] -.->|"Неявно реализует"| I
    end

    style Tight fill:#7f1d1d,stroke:#ef4444,stroke-width:2px,color:#f8fafc
    style Decoupled fill:#1e293b,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
  

Управление IO и неконтролируемой средой

Базы данных — далеко не единственный источник недетерминизма в бэкенде. Любое прямое обращение к операционной системе или глобальным часам превращает тесты в пороховую бочку:

1. Генерация псевдослучайных чисел (math/rand или crypto/rand).
2. Физическое системное время (time.Now()).
3. Операции с файловой системой (os.ReadFile).
4. Сетевые HTTP-вызовы (http.Get).

Паттерн "Clock"

Для тестирования логики, завязанной на течение времени (например, срока жизни сессий, валидации токенов или алгоритмов rate-limiting), системное время обязано передаваться через инъекцию.

Подход 1: Функциональная инъекция (для простых сценариев)

type TokenValidator struct {
    now func() time.Time // Инжектируемая функция получения времени
}

func NewTokenValidator() *TokenValidator {
    return &TokenValidator{now: time.Now} // По умолчанию — боевые системные часы
}

В тесте достаточно подменить поле now = func() time.Time { return fixedDate }.

Подход 2: Интерфейсный паттерн (для сложных распределенных сервисов)

// Clock абстрагирует подсистему системного времени
type Clock interface {
    Now() time.Time
    After(d time.Duration) <-chan time.Time
}

В боевом коде используется реализация RealClock (обертка над стандартным пакетом time), а в тестах внедряется виртуальный генератор времени MockClock, позволяющий мгновенно перематывать виртуальные часы вперед без использования нестабильных пауз time.Sleep.

Mechanical Sympathy: Цена интерфейсов

Внедрение интерфейсов повышает гибкость и тестируемость. Однако в системной инженерии не существует бесплатных абстракций.

Архитектурное резюме:
Интерфейсы великолепны на системных и функциональных границах приложения: репозитории баз данных, клиенты удаленных API, брокеры сообщений, файловые хранилища. Сетевой вызов к PostgreSQL сам по себе занимает 2–5 миллисекунд (сотни тысяч процессорных тактов), поэтому наносекундный оверхед виртуальной таблицы itab там абсолютно незаметен.

Однако категорически запрещено оборачивать в интерфейсы внутренние математические структуры, DTO или парсеры на горячем пути (Hot Path) исключительно ради того, чтобы «написать на них мок». Если вычислительный алгоритм сложен — выделите его в чистую функцию и тестируйте напрямую без абстракций.

Итог

1. Избегайте глобальных переменных (var db *sql.DB) и функций init(). Они разрушают изоляцию тестов и делают параллельное выполнение через t.Parallel() источником Data Races.
2. Внедряйте зависимости явно через конструкторы. Никакой скрытой магии: если сервису нужна база данных, передайте ее в аргументах функции NewService.
3. Используйте интерфейсы на стороне потребителя (Consumer Interfaces). Пакет должен сам объявлять тот минимальный контракт, который ему требуется для работы, а не зависеть от тяжелых структур поставщика.
4. Изолируйте внешнее окружение: системное время (time.Now()), генераторы случайных чисел и сетевые клиенты (http.Get) должны быть управляемыми через паттерны инъекции.
5. Помните о цене динамического вызова: используйте интерфейсы на границах I/O, но держите горячий вычислительный тракт на плоских структурах.

Мы научились проектировать тестируемый код. Но чтобы тестовый пайплайн приносил реальную пользу, тесты обязаны быть абсолютно стабильными. В следующей лекции мы разберем проблему детерминизма: 5. Determinism и воспроизводимость.