Ответ
TDD (Test-Driven Development) — это методология разработки, при которой цикл написания кода строится вокруг тестов. Вместо того чтобы сначала писать код, а потом тесты, разработчик следует короткому итеративному циклу «Красный – Зеленый – Рефакторинг».
Основной цикл TDD:
- Красный (Red): Написать заведомо провальный автоматизированный тест для новой, еще не реализованной функциональности. Тест не должен проходить, потому что код еще не написан.
- Зеленый (Green): Написать минимально необходимый код, чтобы тест прошел. На этом этапе главная цель — заставить тест работать, даже если код не идеален.
- Рефакторинг (Refactor): Улучшить написанный код (удалить дублирование, повысить читаемость, оптимизировать), убеждаясь, что все тесты по-прежнему проходят. Это гарантирует, что изменения не сломали существующую функциональность.
Этот подход заставляет разработчика с самого начала думать о требованиях к коду и его интерфейсах, что приводит к более качественной и поддерживаемой архитектуре.
Пример на Python с использованием pytest
Предположим, мы создаем простую функцию-калькулятор.
Шаг 1: Красный (пишем тест)
Создаем файл test_calculator.py:
# test_calculator.py
from calculator import add
def test_add_positive_numbers():
assert add(2, 3) == 5
# Запуск `pytest` сейчас вызовет ошибку, так как `calculator.py` и функция `add` не существуют.Шаг 2: Зеленый (пишем минимальный код)
Создаем файл calculator.py и реализуем функцию:
# calculator.py
def add(a, b):
return a + b
# Теперь запуск `pytest` покажет, что тест успешно пройден.Шаг 3: Рефакторинг
В данном простом случае код уже оптимален. Но если бы реализация была сложнее, на этом этапе мы бы улучшали ее, например, добавляя обработку ошибок или оптимизируя алгоритм, при этом сохраняя прохождение теста.
Ответ 18+ 🔞
Да ты посмотри, что эти умники придумали! TDD, блядь! Test-Driven Development, ёпта! Это ж когда ты не пишешь код, как нормальный человек, а начинаешь с тестов, как какой-то извращенец, сука!
Представь картину: сидит программист, и у него в голове ещё ни одной строчки кода, а он уже пишет тест, который заведомо сломается! Это ж надо так мозги себе вывернуть, блядь! Но, сука, в этом есть своя, ебаная, гениальность.
Вот смотри, как они это делают, эти фанатики. У них три шага, как в каком-то ебучем танце: Красный, Зеленый, Рефакторинг.
Первое действие, Красное (Red): Ты пишешь тест на то, чего ещё нет. Вообще. Функции add не существует, но ты уже пишешь, что она должна 2 и 3 складывать в 5. Запускаешь тест — он, естественно, падает, как подстреленный селезень. Весь в красных ошибках. Цель достигнута, можно радоваться, блядь! Ты успешно написал код, который не работает! Ёперный театр!
Второй акт, Зелёный (Green): А вот тут начинается магия, сука. Твоя задача — написать самый тупой, самый минимальный код, чтобы этот ёбаный тест наконец-то прошёл. Не красивый, не умный, а просто рабочий. Создаёшь файлик calculator.py, пишешь туда def add(a, b): return a + b и всё, пиздец. Запускаешь тесты — они зелёные! Ура, товарищи! Функция складывает два числа! Нобелевку давайте, блядь!
И наконец, Рефакторинг: А вот теперь, когда тесты зелёные и всё работает, можно выдохнуть и подумать: «А не говнокод ли я, сука, написал?». И начинаешь этот код причёсывать: убирать дубли, переименовывать переменные, выносить логику. И главное — после каждого чиха запускаешь тесты. Если они зелёные — значит, ты ничего не сломал. Если красные — значит, ты мудак и надо откатываться. Просто, как три копейки, но мозг сломать можно.
Давай на живом примере, чтоб понятно было, как об стенку горох!
Допустим, нам нужен калькулятор, который складывает. По TDD-шной логике, мы начинаем не с калькулятора, а с теста на него. Полный пиздец, но окей.
Шаг 1: Красный (Пишем провальный тест)
Создаём файл test_calculator.py и ваяем там такое:
# test_calculator.py
from calculator import add # Смотри, какая наглость! Импортируем то, чего нет!
def test_add_positive_numbers():
assert add(2, 3) == 5 # И требуем, чтобы оно работало!Запускаешь pytest — и он тебе, естественно, в ответ: «Модуль calculator не найден, иди на хуй». Тест красный. Отлично, первый этап пройден, можно идти пить чай.
Шаг 2: Зелёный (Пишем хоть какой-то код)
Теперь создаём этот самый calculator.py и пишем ровно столько, чтобы заткнуть тест.
# calculator.py
def add(a, b):
return a + b # Всё, гений. Сложил и доволен.Запускаешь тесты — и охуеваешь! Они зелёные! Функция работает! Кайф, блядь!
Шаг 3: Рефакторинг (Прибираемся в своём же дерьме)
Смотрим на код. def add(a, b): return a + b. Ну, вроде и придраться не к чему, идеально, блядь. Но если бы тут была сложная логика, вот тут бы мы её и начали полировать, не боясь ничего сломать, потому что тесты-то наши сторожат!
Вот и вся философия, блядь. Сначала пишешь контракт (тест) на то, что хочешь получить. Потом выполняешь этот контракт самым простым способом. А потом приводишь выполнение в божеский вид. И всё это под непрерывным присмотром автоматических тестов, которые орут, если ты накосячил.
С одной стороны — ебать какая дисциплина! С другой — иногда так и хочется крикнуть: «Да отойди ты от меня со своими тестами, дай просто код написать, сука!». Но, говорят, привыкаешь.