in Русский

Пять плюшек TDD

Надеюсь что читатель знаком с TDD (Разработка через тестирование). Если нет, кратко:
При разработке по TDD важно следовать трём этапам.

  1. Красный (Red): Напишите код теста, который приводит к ошибке. Включая ошибки компиляции.
  2. Зелёный (Green): Напишите достаточное количество продакшн кода, который нужен для прохождения теста, не
    более.
  3. Устранение дублирования (Refactoring): Удалите дублирование кода между тестом и продакшн кодом, улучшите
    читабельность, названия переменных и так далее.
    Повторить.

Этот цикл улучшит продуктивность, уменьшит стресс на проекте и поможет выкатывать фичи (features) быстрее.
Уже применяете эту дисциплину? Моё уважение, продолжайте в том же духе!
Если пробовали TDD и разочаровались, ниже 5 плюсов, которые убедят вас разрабатывать по TDD.

Уменьшение сложности

TDD уменьшает сложность кода. Пишем код, который проходит тест, ни больше, ни меньше. Пишем тест, который падает. Пишем минимальное
количество продакшн код для прохождения теста. Устраняем дублирование. Следуя этому циклу, вы не напишете неиспользуемый, ненужный код. Или не покрытую тестами фичу. Чем меньше кода на проекте, тем меньше дефектов. QA меньше времени потратит на тестирование и проверку релиза. Также меньше проблем с поддержкой кода в будущем.

Меньше дебага (debugging)

Распространённый инструмент локализации ошибок – процесс дебага. Моё мнение дебажить сложно и дорого – запустить приложение
и выполнить ряд шагов, чтобы вызвать и проверить реализованную фичу. Не один раз. Думаете это умение ценится командой или заказчиком? Едва ли. Разработка через тестирование помогает быстро локализовать ошибки при разработке, ещё до запуска приложения. Всегда пока вы поддерживаете тесты. Это лучше чем тратить часы на дебаг.

Маленькие шаги дают больше контроля

Сталкиваясь со сложной задачей, разработчик иногда застревает на месте. Маленькие шаги помогают разрабатывать строка за строкой, даже если не знаете как реализовать текущую задачу. Ещё лучше – комиттить каждый маленький шаг в VCS. Написали тест, который падает – время сделать коммит. Написали достаточное количество кода чтобы тест прошёл. Супер – коммитим изменения.
Порефакторили код, и тесты проходят – время коммита.

Легко рефакторить

Агрессивно рефакторить легче когда код покрыт тестами. Переименовывать функции и переменные, менять расположение, дробить код на функции, заменять алгоритмы на более эффективные и так далее. Тесты помогают изменять код и проверить себя.
С тестами легче следовать правилу Бойскаута.

Тесты определяют реализацию

Писать тесты на фичу после реализации скучно. Код работает, зачем тратить время? Вы уже потратили времени на дебаг и ручное тестирование. Гарантируют ли тесты, написанные после фичи, отсутствие дефектов? Тесты после реализации
тестируют только то, что уже реализовано. Реализация диктует какими будут тесты, не наоборот. TDD подразумевает что, при работе над фичей сначала идёт брейншторм, 5-10 минут, о всевозможных входных/выходных параметрах и исключительных ситуациях. Записали в блокнот, выбрали простейший случай и написали тест. Кейсы из блокнота оформляются как тесты. Также мысли, которые возникли при разработке тестов и продакшн кода, добавляются в блокнот и превращаются в тесты. Иными словами, тесты определяют реализацию.

Итого

  • Кода столько, сколько нужно. Без переусложнений
  • Меньше дебажим, больше времени уделяем разработке
  • Маленькие шаги помогают со сложной задачей. Ясные и краткие коммиты
  • Непрерывно улучшаем качество кода
  • Покрываем тестами нормальные и исключительные случаи фичи

Надеюсь что этот пост заинтересовал разрабатывать по TDD. В следующих постах будут примеры как добиться этих плюшек, расскажу на чём заострить внимание. Увидимся!

Write a Comment

Comment