Эта статья представляет собой хороший теоретический материал о TDD для тех, кто об этом ещё ничего не знает.
В мире разработки ПО существует общее заблуждение, что простое написание тестов равносильно разработке через тестирование.
Разработка через тестирование(TDD) даёт уверенность в работоспособности программы в любой момент времени и помогает всем её частям быть хорошо спроектированными, использоваться повторно и слабо связываться.
Что такое TDD?
В TDD есть 3 основных правила от дядюшки Боба:
- Пиши только тот код, который протестирован.
- Начинай писать тесты с малого, а затем наращивай их.
- Пиши ровно столько кода, сколько необходимо для прохождения теста.
Основы TDD
Базовый процесс следования TDD содержит 3 этапа: красный, зелёный и рефакторинг.
Красный
Красный этап состоит из написания теста, который не проходится. Только одного теста. Если ты не можешь остановиться и продолжаешь писать много тестов, займи идею из Getting Things Done и выкинь лишние мысли из головы, чтобы они не отвлекали тебя. Существует несколько разных способов, которые ты можешь использовать: создать список предстоящих дел на бумаге, нарисовать индексную карту, добавить серию TODO комментариев в свои файлы и многие другие. Для себя я определил, что физическое действие вычёркивания пунктика на бумаге или рисование галочки и сворачивание индексной карты пополам даёт мне большее ощущение завершённости дела.
Твой первый тест для нового объекта должен быть простым. TDD фокусируется на возникающем проектировании - противоположности большому проектированию наперёд. Пусть дизайн получается из твоего кода. Назначение первого теста - это не функциональность, а определение границ использования того, что ты сейчас создаёшь.
Начни с вводных: "Что я буду передавать этому действию?". После этого подумай о результатах: "Что эта функция будет возвращать?". Напиши предположение, запусти тесты и убедись, что твой новоявленный тест красный.
Все остальные тестовые случаи на красном этапе должны фокусироваться на разрабатываемую функциональность. Не иди простыми дорогами, думай о самых непредсказуемых вещах, которые ты можешь сделать с функцией или объектом. Что произойдёт если передать параметр null? Что произойдёт, когда я передам отрицательное число? А как насчёт передачи строки, когда код ожидает увидеть число?
Зелёный
Зелёный этап заключается в прохождении падающих тестов как можно скорее. Если более одного теста падают, начни с исправления того, который ты только что написал, а потом продолжи исправление других красных тестов по одному. Не думай о том, как выглядит твой код или насколько он эффективен. Твоя цель должна быть в прохождении теста, чтобы ты мог удостовериться, что ещё одна часть функциональности покрыта тестами.
Рефакторинг
Следующий шаг - это рефакторинг, реструктуризация и организация твоего кода. Этап рефакторинга может происходить в любой момент: после 1 красного/зелёного цикла, после четырёх или более. Так как у тебя есть по меньшей мере 1 зелёный тест, ты можешь переписывать код с лёгкостью и комфортом, зная, что твои тесты провалятся, если ты ошибёшься и потеряешь работащую функциональность.
Рефакторинг должен касаться только реструктуризации своего кода и придания ему более читаемого вида. Не забывай уделять внимание и усовершенствованию тестов, но не делай рефакторинг кода и тестов одновременно.
Преимущества TDD
Рабочий код
Одно из преимуществ TDD - это постоянное наличие правильно работающего кода. Ты вкладываешь время в работоспособность кода и ты всегда можешь быть уверен, что он работает как задумано.
Изменения без страха
TDD позволяет не бояться изменений. Я работал во множестве проектов, прежде чем ощутил преимущества TDD. Оглядываясь назад, я могу сказать, что всегда боялся вносить изменения в код. Я проводил много времени, тестируя приложение вручную для того, чтобы убедиться что я не сломал его работоспособность. С приходом TDD этот страх ушёл - функциональность всегда покрыта тестами, и ты способен получить почти моментальный отклик от системы или любой её части. В то же время отсутствие страха перед рефакторингом повышает внутреннее качество твоей программы, что положительно сказывается и на внешнем качестве.
Живая документация
TDD обеспечивает тебя живой документацией кода. Если ты такой же как и я, то изучение новой библиотеки у тебя начинается не с пушистой документации, а с примеров использования. Очень важно понимать и следовать тому, что при написании или рефакторинге тестов мы должны сохранять их читаемость и простоту алгоритма. В отличии от комментариев или длинных документаций, тесты исполнимы и всегда сообщат, когда они врут.
Архитектура через код
Я всегда переживал, что одна из D в TDD не означает дизайн. Как я мельком упоминал ранее, практика TDD это не только написание тестов в попытке удостовериться, что программа работоспособна. TDD переворачивает разработку программ вверх ногами и заставляет думать о проблеме не изнутри, а снаружи.
Написание тестов заставляет тебя думать не о реализации - основное беспокойство связано с использованием объекта или функции. Так как мы проводим большое количество времени непосредственно взаимодействуя с объектами и функциями которые мы пишем, архитектура проявляется из кода сама.
Когда не TDD
Что если тебе нужно использовать новую библиотеку или фреймворк, а ты не знаешь как это сделать? Как ты можешь написать тест в первую очередь, если ты не знаешь с чего начать? Ответ прост - а ты не можешь. Создай новый проект и используй новую библиотеку отдельно от своего рабочего кода. Такие новые проекты называются костылями. Так как они не в твоём рабочем коде, ты не нарушаешь Правило №1 из трёх правил дядюшки Боба. Работай с ним пока ты не почувствуешь комфорт в использовании этой библиотеки. Когда узнаешь, как твоя библиотека работает, забудь костыли и возвращайся назад к своему рабочему коду и начинай с написания тестов.
Как бы то ни было, если ты не можешь использовать TDD, не забывай о важности написания тестов. Твои тесты послужат справкой для тебя и (если твой костыль в системе контроля версий) для тех, кто придёт после тебя. С помощью этих тестов ты можешь быстро вспомнить всё что ты изучил, и, оглядываясь назад, ты увидишь большой прогресс в своём мастерстве.