Teamlead Roadmap
Подписывайтесь на Telegram-канал Teamlead Good Reads: ежедневные статьи про управление людьми, командами и процессами!

# Unit-тестирование

# Описание

Unit-тестирование (модульное тестирование) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, функции или методы.

Цель использования данного процесса:

  • Сформулировать требования к поведению конкретного модуля
  • Повысить доверие к исходному коду
  • Обеспечить качество путём быстрого обнаружения ошибок
  • Поддержать хороший дизайн системы
  • Дать возможность непрерывно интегрироваться

# Почему ветка важна?

Для менеджера:

  • Увеличение скорости разработки в среднесрочной перспективе
  • Снижение стоимости разработки в среднесрочной перспективе

Для разработчика:

  • Доверие своему и чужому коду
  • Возможность правильно спроектировать систему

# Что будет, если её не делать?

  • Увеличится цикл обратной связи - дефекты находим позже, например, только на ручном регрессе, что затягивает проект в целом
  • Вырастет количество дефектов из-за невозможности постоянно запускать тесты после изменения исходного кода
  • Команда разработки потеряет контроль над кодовой базой - проще сделать новый функционал "рядом", чем менять существующий
  • Система быстро устареет и потребуется переписать её с нуля

# На кого может быть делегирована?

  • Тимлид уровнем ниже
  • Разработчик

# Примеры поведения

# Примеры плохого поведения

  • Не писать unit-тесты в целом - проверка качества ПО смещается в сторону более дорогих способов, например, интеграционного тестирования
  • Писать unit-тесты, не опираясь на "хорошие практики" - снижается их эффективность, что часто ведёт к полному отказу от данной практики в команде/проекте
  • Не запускать unit-тесты, в том числе автоматически - практически то же самое, что их не писать или не актуализировать
  • Пропускать при запуске или отключать неуспешные unit-тесты - ведёт к снижению доверия к ним

# Примеры хорошего поведения

  • Писать unit-тесты перед реализацией - подход TDD
  • Покрывать тестами ранее непокрытый код - снижение рисков при его модификации и рефакторинге
  • Использовать Заглушки и Тестовые дублёры - изоляция тестируемого кода
  • Использовать DSL Domain Specific Language - повышение читаемости тестового кода
  • Актуализировать/дополнять unit-тесты при исправлении новых дефектов, что позволяет учесть ранее пропущенное требование и предотвращает появление дефекта вновь

# Способы прокачки

# Практика

Чтобы отработать навыки написания unit-тестов, можно использовать KataCatalogue - сборник простых примеров, на которых можно потренироваться

# Консультации

# Теория

Тест считается по-настоящему модульным, если обладает следующими свойствами:

  • Сфокусированный - проверяет только одно утверждение
  • Ценный - отражает актуальное требование
  • Независимый - от других тестов или окружения, на котором выполняется
  • Быстрый - выполняется достаточно быстро, чтобы запускаться при каждом изменении кода
  • Понятный - соблюдается структура, конвенция именования, имеет маленький размер
  • Поддерживаемый - меняется с течением времени

Хорошей структурой unit-теста является подход AAA: Arrange(условие), Act (действие), Assert (утверждение):

class CalculatorShould
{
  @Test
    public void returnSumOfTwoIntegerNumbers()
  {
    // Arrange
    Calulator calculator = new Calculator();

    // Act
    Inreger result = calculator.sum(1,1);

    // Assert
    assertEquals(2, result);
  }
}

# Статьи

# Книги

← Тестирование требований →