Как выводить данные в Go-тестах: секреты t.Log() и t.Logf() в 2025

Онлайн-тренажер Python для начинающих

Изучайте Python легко и без перегрузки теорией. Решайте практические задачи с автоматической проверкой, получайте подсказки на русском языке и пишите код прямо в браузере — без необходимости что-либо устанавливать.

Начать курс

Введение: Вечный вопрос "А как же вывести что-то в тесте?"

Вы пишете тест на Go. Логика сложная, данные запутанные, и вам жизненно необходимо увидеть, что происходит внутри. Вы машинально пишете fmt.Println("value =", x), запускаете тест... и видите тишину. Никакого вывода. Знакомо?

Этот вопрос — один из самых популярных на Stack Overflow среди начинающих (и не только!) Go-разработчиков. Кажется, что может быть проще, чем вывести строку? Но в мире тестирования Go есть свои правила и джентльменский набор инструментов. В этой статье мы разберём все способы вывода в тестах, разложим по полочкам лучшие практики 2025 года и покажем, как не наломать дров. Поехали!

Почему `fmt.Println` молчит? (И когда он всё-таки заговорит)

Давайте сразу к делу. Когда вы запускаете тесты командой go test (без флагов), стандартный вывод (stdout) подавляется. Go-тестировщик считает, что если тест прошёл успешно, то пользователю не нужно видеть тонны отладочной информации. Это сделано для чистоты и автоматизации — представьте, если бы каждый тест выводил по 10 строк лога при каждом запуске CI/CD.

Однако есть два исключения, когда fmt.Println всё же покажется на экране:

Флаг -v (verbose): go test -v. Этот режим включает подробный вывод всех тестов. Вы увидите сообщения от fmt.Println и других функций.
Тест упал: Если тест завершился с ошибкой (вызван t.Error или t.Fatal), то вывод fmt.Println из этого теста будет показан. Это очень полезно для отладки.

Но полагаться на fmt.Println — моветон. Для тестов в Go есть специальный, более правильный и мощный инструмент.

Король вечеринки: `t.Log()` и `t.Logf()`

Объект testing.T (который передаётся в каждый тест) имеет встроенные методы для логирования. Запомните их как "Отче наш": t.Log() и t.Logf().

package main

import (
    "testing"
)

func TestSum(t *testing.T) {
    result := 2 + 2
    // Простое логирование
    t.Log("Начинаем тест суммы")
    t.Log("Результат вычисления:", result)

    // Логирование с форматированием (как fmt.Printf)
    t.Logf("Сумма 2 и 2 равна %d. Проверка пройдена!", result)

    if result != 4 {
        t.Errorf("Ожидали 4, получили %d", result)
    }
}

Запустите этот тест с флагом -v:

go test -v -run TestSum

И вы увидите красивые, структурированные сообщения прямо в выводе теста.

Почему `t.Log` лучше, чем `fmt.Println`?

Контекст: Сообщения от t.Log автоматически привязываются к конкретному тесту. В выводе -v вы видите, какой тест что напечатал.
Управляемость: Вывод t.Log показывается только при -v или при падении теста. Это значит, что ваши логи не засоряют консоль при обычном запуске.
Безопасность: В отличие от fmt.Fprintf(os.Stderr, ...), t.Log корректно работает с параллельными тестами (t.Parallel) и не вызывает race condition.

Тёмная сторона силы: `t.Error()` и `t.Fatal()` как инструмент вывода

Многие новички используют t.Error() только для того, чтобы остановить тест при ошибке. Но на самом деле это отличный (и правильный!) способ вывести важную диагностическую информацию, особенно когда тест падает.

Секрет в том, что сообщение, переданное в t.Error() или t.Fatal(), всегда будет показано, даже без флага -v. Это делает их идеальными для вывода критических данных, которые помогут понять причину провала.

func TestDivide(t *testing.T) {
    a, b := 10, 0
    if b == 0 {
        // Это сообщение увидят все, даже если запустить go test без флагов
        t.Fatal("Ошибка: деление на ноль! Немедленная остановка теста.")
    }
    result := a / b
    t.Logf("Результат деления: %d", result)
}

Запустите go test (без -v), и вы увидите в консоли:

--- FAIL: TestDivide (0.00s)
    main_test.go:9: Ошибка: деление на ноль! Немедленная остановка теста.
FAIL

Это мощный приём: используйте t.Log для отладочной информации, а t.Error/t.Fatal — для сообщений об ошибках, которые должны быть видны всегда.

Продвинутые техники: Временные метки и структурированные логи

В 2025 году просто писать t.Log("что-то пошло не так") уже недостаточно. Хорошие тесты — это читаемые тесты. Вот несколько приёмов, которые сделают вашу отладку в 10 раз быстрее.

1. Добавляйте временные метки

Если ваш тест выполняет несколько шагов или работает с таймаутами, добавьте время. Это поможет понять, на каком этапе произошла задержка.

func TestSlowOperation(t *testing.T) {
    start := time.Now()
    t.Log("Начало теста в:", start.Format(time.RFC3339))

    // ... какой-то код ...
    time.Sleep(100 * time.Millisecond)

    t.Logf("Первый этап завершён за %v", time.Since(start))
    // ... ещё код ...
    t.Logf("Общее время выполнения: %v", time.Since(start))
}

2. Структурированный вывод (JSON)

Для сложных сценариев, особенно когда тесты запускаются в CI, удобно выводить структурированные данные, которые потом легко парсить.

func TestUserCreation(t *testing.T) {
    user := map[string]interface{}{
        "id":    1,
        "name":  "Alice",
        "email": "alice@example.com",
    }
    // Выводим как JSON для красивого форматирования
    data, _ := json.MarshalIndent(user, "", "  ")
    t.Logf("Создан пользователь:\n%s", data)
}