Цитаты из книги «Экстремальное программирование. Разработка через тестирование»

Красный—зеленый—рефакторинг — это мантра TDD.

Прежде чем что-либо менять в коде, вы должны написать все тесты, которые кажутся вам необходимыми. Если этого не сделать, рано или поздно, выполняя рефакторинг, вы чего-нибудь поломаете. Код перестанет работать так, как должен. Вы потратите кучу времени на поиск ошибки и сформируете предубеждение против рефакторинга. Если подобный инцидент повторится, вы можете вообще перестать делать рефакторинг. Дизайн начнет деградировать. Вас уволят с работы. От вас уйдет ваша любимая собака. Вы перестанете мыться и чистить зубы. У вас начнется кариес. Чтобы сохранить зубы здоровыми, всегда сначала пишите тесты и только после этого выполняйте рефакторинг.

Сначала сделаем, чтобы код заработал, потом сделаем, чтобы код был правильным (make it run, make it right).

1. Написать тест. 2. Добиться его безошибочной компиляции. 3. Запустить тест и убедиться, что он потерпел неудачу. 4. Добиться успешного выполнения теста. 5. Устранить дублирование.

в любой момент времени вы должны быть не дальше одного изменения от зеленой полосы.

перед тем как писать любой фрагмент кода, создайте автоматизированный тест, который поначалу будет терпеть неудачу;

Чтобы обеспечить более полноценное тестирование, попробуйте использовать 2 в качестве первого аргумента и 3 в качестве второго аргумента (в свое время тест 3 + 4 был классическим начальным тестом при запуске новой виртуальной машины Smalltalk).

Приложение II. Фибоначчи В ответ на просьбу одного из моих рецензентов я включил в книгу описание разработки функции вычисления последовательности Фибоначчи в стиле TDD. Некоторые утверждают, что именно этот пример раскрыл им глаза на механику работы TDD.

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

Я всегда стараюсь размещать операции рядом с данными.