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

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

За более чем 10 лет работы в QA я глубоко погружался в модульное тестирование (Unit Testing), особенно при взаимодействии с разработчиками в рамках процессов Agile/Scrum и CI/CD. Модульные тесты — это фундамент пирамиды тестирования, и я фокусировался на нескольких ключевых аспектах.

1. Тестирование отдельных функций и методов

Это ядро unit-тестирования. Я проверял, что каждая функция, метод или класс ведут себя корректно при различных входных данных.

• Логика условий и циклов: Проверка всех ветвлений if/else, switch, циклов for/while. Например, для функции расчета скидки:

def calculate_discount(amount, is_member):
    if amount > 1000:
        return amount * 0.9
    elif is_member and amount > 500:
        return amount * 0.95
    else:
        return amount

Писал тесты для случаев: amount=1200, amount=600, is_member=True, amount=600, is_member=False, amount=300.

• Математические операции и преобразования данных: Корректность вычислений, обработка округления, преобразование типов (например, строк в числа).
• Валидация входных параметров: Как функция реагирует на некорректные данные (None, пустые строки, отрицательные числа, неожиданные типы). Использовал тесты на исключения (assertRaises в Python/JUnit).

2. Тестирование граничных условий и эквивалентных разделов

• Граничные значения (Boundary Value Analysis): Для параметров с диапазонами. Например, если скидка применяется при покупке от 1000 руб., тестировал суммы 999, 1000 и 1001.
• Эквивалентные классы: Группировка входных данных, где поведение функции ожидается одинаковым. Например, для валидации пароля: валидные пароли (класс 1), слишком короткие (класс 2), без цифр (класс 3).

3. Тестирование зависимостей и изоляции

Unit-тесты должны быть изолированными. Я активно работал с моками (mocks), стабами (stubs) и шпионами (spies) для изоляции тестируемого модуля.

• Заглушка внешних сервисов: Например, мок HTTP-клиента для вызова API, чтобы не зависеть от сетевых проблем или доступности стороннего сервера.
• Имитация баз данных: Подмена реальных DAO/Repository объектов, чтобы тесты не требовали развернутой БД и были быстрыми.

// Пример на Java с Mockito
@Mock
private UserRepository userRepositoryMock;

@Test
public void testUserServiceFindUser() {
    when(userRepositoryMock.findById(1L)).thenReturn(new User("John"));
    UserService service = new UserService(userRepositoryMock);
    User result = service.findUser(1L);
    assertEquals("John", result.getName());
    verify(userRepositoryMock).findById(1L); // Проверка взаимодействия
}

4. Тестирование состояния и поведения

• Состояние объекта: Проверка, что после вызова метода объект перешел в ожидаемое состояние (значения полей изменились корректно).
• Поведение (interaction testing): Проверка, что метод правильно взаимодействует с другими объектами (вызвал нужный метод с правильными аргументами определенное количество раз). Это критично для архитектурных паттернов типа MVC, MVP.

5. Работа с legacy-кодом и рефакторингом

Часто приходилось писать модульные тесты для существующего, плохо покрытого кода (legacy code), чтобы обеспечить безопасный рефакторинг. В таких случаях:

• Начинал с наиболее критичных по бизнес-логике модулей.
• Использовал техники вроде "золотого мастера" (Golden Master) для регрессионного тестирования, если код был плохо структурирован.

6. Интеграция в процесс разработки

Я не просто писал тесты, а обеспечивал их интеграцию в процесс CI/CD:

• Покрытие кода (Code Coverage): Отслеживал метрики (statement, branch coverage) с помощью инструментов вроде JaCoCo (Java), Coverage.py (Python). Стремился к осмысленному покрытию критических ветвлений, а не просто к 100%.
• Запуск в пайплайне: Настройка автоматического запуска юнит-тестов при каждом коммите (pre-commit hook) и в сборке (Jenkins, GitLab CI).
• Читаемость и поддержка тестов: Следовал принципам FIRST (Fast, Independent, Repeatable, Self-validating, Timely). Использовал понятные имена тестовых методов (pattern: methodName_stateUnderTest_expectedBehavior).

Ключевые технологии и фреймворки

В зависимости от стека проекта я применял:

• Java: JUnit 4/5, TestNG, Mockito, PowerMock, AssertJ.
• Python: unittest, pytest, nose, unittest.mock.
• JavaScript/TypeScript: Jest, Mocha + Chai + Sinon, Jasmine.
• C#: NUnit, xUnit, MSTest, Moq.

В итоге, модульное тестирование для меня — это не просто «проверить функцию», а создание защитного сетка, который позволяет команде быстро и безопасно вносить изменения, рефакторить код и гарантирует корректность базовой логики. Это совместная ответственность разработчика и QA-инженера, где QA часто выступает в роли консультанта по качеству кода, проектированию тестов и выбору стратегии покрытия.