Pull to refresh

Простое написание тестов — это не TDD!

Reading time 4 min
Views 61K
Original author: Tony Baker
Эта статья представляет собой хороший теоретический материал о 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, не забывай о важности написания тестов. Твои тесты послужат справкой для тебя и (если твой костыль в системе контроля версий) для тех, кто придёт после тебя. С помощью этих тестов ты можешь быстро вспомнить всё что ты изучил, и, оглядываясь назад, ты увидишь большой прогресс в своём мастерстве.
Tags:
Hubs:
+60
Comments 121
Comments Comments 121

Articles