Подход Test-Driven Development (TDD) появился более 20 лет назад, думаю сложно найти разработчика который о нем не слышал. Однако, до сих пор, существует множество споров о его применимости на “реальном коде”. Понятно, как (но не всегда просто) написать тесты на существующий код, но как их писать когда нет? В этом посте я, вдохновившись статьей Кента Бэка (открывателя TDD), попытаюсь снизить порог входа.
Разработчику необходимо изменить поведение системы (которая может в принципе ещё не существовать данный момент). TDD призван помочь программисту создать новое состояние системы, в котором:
- Все, что работало раньше, продолжает работать.
- Новое поведение работает так, как ожидалось.
- Система готова к следующим изменениям.
- Разработчик и его коллеги чувствуют уверенность в вышеуказанных пунктах.
Шаги
1. Создайте список тестов
Первый шаг в TDD, заключается в перечислении всех ожидаемых вариантов нового поведения. «Вот основной вариант, а что, если этот сервис выйдет из строя, а что, если ключа еще нет в базе данных и...»
Это анализ, но анализ поведения. Вы думаете обо всех различных случаях, в которых изменение поведения должно сработать. Если вы думаете о том, как изменение поведения не должно нарушить существующее поведение, добавьте и это.
Предупреждение: не перемешивайте решения по дизайну реализации. У вас будет достаточно времени, чтобы решить, как будет выглядеть внутренняя часть, позже. Вы лучше справитесь с перечислением тестов, если сосредоточитесь только на этом. Если вам нужен эскиз реализации, нарисованный ручкой на салфетке, - вперед, но на самом деле он может и не понадобиться. Экспериментируйте.
2. Напишите тест
Один тест. По-настоящему автоматизированный, с настройкой (arrange), вызовом (act) и утверждениями(assert).
Совет: попробуйте поработать с утверждениями (assert) в обратном направлении. Именно в процессе написания этого теста вы начнете принимать решения по дизайну, но в первую очередь это будут решения по интерфейсу. Некоторые решения по реализации могут просочиться сквозь них, но со временем вы научитесь избегать этого.
Предупреждение: не пишите сразу все тесты из списка. Прохождение первого теста заставит вас пересмотреть решение, которое повлияет на все остальные тесты. Это истощает разработчика.
Выбор следующего теста - важный навык, который приходит только с опытом. Порядок тестов может существенно повлиять, как на опыт программирования, так и на конечный результат.
3. Сделайте так, чтобы тест прошел
Теперь, когда у вас есть падающий тест, измените систему так, чтобы тест прошел.
Предупреждение: не копируйте вычисленные значения теста. Это разрушает двойную проверку, которая создает большую часть ценности TDD.
Предупреждение: не смешивайте рефакторинг с выполнением теста. Сначала напишите тест, а затем сделайте его правильным. Ваш мозг (со временем) скажет вам спасибо.
Если в процессе перехода от красного к зеленому вы обнаружите необходимость в новом тесте, добавьте его в список тестов. Если этот тест делает недействительной уже проделанную работу («О, нет, здесь нет возможности обработать случай с пустой папкой»), вам нужно решить, стоит ли продолжать в этой точке или лучше начать сначала.
Совет: начните сначала, но выберите другой порядок выполнения тестов.
Когда тест пройден, вычеркните его из списка.
4. По желанию проведите рефакторинг
Теперь вы можете принимать решения по дизайну реализации.
Предупреждение: не проводите рефакторинг дольше, чем необходимо для этой сессии. Приятно наводить порядок. Понимаю, страшно встретиться со следующим тестом, особенно если вы не знаете, как его пройти.
Предупреждение: не создавайте абстракции слишком быстро. Дублирование - это подсказка, а не приказ.
5. Пока список тестов не пустой, перейдите к пункту 2
Продолжайте тестировать и писать код, пока ваш страх за поведение кода не превратится в скуку.
Попробуйте (возможно несколько раз) этот несложный алгоритм и будьте готовы удивиться насколько результат получается проще, стабильнее и надежнее.
Published by Сергей Лобин
Тему TDD, а также и другие сопутствующие профессиональному Скраму практики мы разбираем на нашем тренинге Applying Professional Scrum for Software Development (APS-SD)
