Модульное тестирование

Введение: Проверка деталей

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

Модульное тестирование — это проверка деталей. В мире API это проверка одного метода, одной функции, одного класса в изоляции от остальной системы.

Модульное тестирование (Unit Testing) — это тестирование наименьших тестируемых частей приложения (методов, функций, классов) в изоляции от внешних зависимостей.

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

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

Место модульного тестирования в пирамиде тестов

    graph TD
    A[E2E тесты<br>мало, медленные] --> B[Интеграционные тесты<br>средне, средние]
    B --> C[Модульные тесты<br>много, быстрые]
  

Почему модульные тесты — основа пирамиды:

• Их много (покрывают все ветки кода)
• Они быстрые (можно запускать после каждого изменения)
• Они дёшевы (не требуют развёртывания инфраструктуры)
• Они точные (указывают на конкретную строку, где проблема)

Что тестируют модульные тесты API

Входная валидация

Бизнес-логика

Обработка ошибок

Пограничные случаи

Изоляция: Что такое mock

Модульные тесты не должны зависеть от внешних систем. Для этого используют mock (заглушки).

Зависимости, которые нужно изолировать

Пример: Проверка бизнес-логики без БД

Вместо реальной базы данных тест использует mock репозитория.

Покрытие кода (Code Coverage)

Что это

Процент кода, который выполняется во время тестов.

Как интерпретировать покрытие

Важное предупреждение: Высокое покрытие не гарантирует качество. Можно написать тест, который выполняет строку, но не проверяет результат. Покрытие — это количество, а не качество.

Что аналитик должен знать о модульных тестах

Какие требования можно проверить модульными тестами

Как читать результаты модульных тестов

TestCreateUser_Success PASSED (0.02s)
TestCreateUser_MissingName FAILED (0.01s)
    expected: 400 Bad Request
    actual:   200 OK
    user_test.go:45: response.StatusCode = 200, want 400

Что видит аналитик:

• Какой тест упал (TestCreateUser_MissingName)
• Почему упал (ожидал 400, получил 200)
• Где искать проблему (user_test.go:45)

Какие вопросы задать команде

Хорошие и плохие модульные тесты

Хороший тест (понимает аналитик)

Тест: Создание пользователя с валидными данными
Действие: POST /users с {name: "Иван", email: "ivan@example.com"}
Ожидание: 201 Created, тело содержит id и name
Результат: PASSED

Плохой тест (непонятен аналитику)

Тест: userCreateTest
Действие: someFunction("test", 123)
Ожидание: !null
Результат: PASSED

Признаки хорошего модульного теста:

Модульные тесты и CI/CD

Где запускаются тесты

    graph LR
    A[Разработчик\nлокально] --> B[Git commit]
    B --> C[CI сервер\nзапуск тестов]
    C -->|Все тесты прошли| D[Деплой]
    C -->|Тесты упали| E[Остановка\nуведомление]
  

Что происходит при падении тестов

Что должен знать аналитик о CI

• Как часто падают тесты? (редко — хорошо, часто — плохо)
• Сколько времени идут тесты? (минуты — хорошо, часы — плохо)
• Кто чинит упавшие тесты? (команда разработки)
• Есть ли отчёт о покрытии? (дашборд)

Связь модульных тестов с требованиями

Traceability (прослеживаемость)

Хорошая практика — связывать тесты с требованиями.

Что даёт аналитику:

• Понимание, какие требования покрыты тестами
• Быстрая оценка влияния изменения требования
• Обоснование, почему тест нужен

Частые проблемы с модульными тестами

Проблема 1: Хрупкие тесты (Brittle tests)

Тесты падают при любом изменении кода, даже не влияющем на поведение.

Пример: Тест проверяет точное сообщение ошибки, а разработчик изменил текст.

Решение: Проверять код ошибки, а не сообщение.

Проблема 2: Медленные тесты

Модульные тесты, которые работают секунды (должны — миллисекунды).

Решение: Изолировать зависимости (БД, сеть, файлы).

Проблема 3: Flaky tests (нестабильные)

Тест то проходит, то падает без изменения кода.

Решение: Убрать случайность, зависимости от времени, порядка выполнения.

Проблема 4: Тестирование реализации, а не поведения

Тест проверяет, как метод делает, а не что делает.

Решение: Тестировать контракт (вход → выход), а не внутреннюю реализацию.

Резюме

1. Модульное тестирование — проверка наименьших частей приложения (методов, функций) в изоляции. База пирамиды тестов.

2. Что проверяет: входную валидацию, бизнес-логику, обработку ошибок, пограничные случаи.

3. Что не проверяет: производительность, безопасность (полностью), совместимость, доступность.

4. Изоляция (mock) — ключевое понятие. Тесты не должны зависеть от БД, сети, времени, случайности.

5. Покрытие кода (coverage) — процент проверенного кода. >80% строк, >70% веток — хорошо. Но покрытие не гарантирует качество.

6. Хороший тест: понятное имя, одна проверка, независим, детерминирован, быстр.

7. В CI/CD: тесты запускаются при каждом коммите. Если тесты падают — деплой останавливается.