TDD

TDD (Test-Driven Development) — сначала пишешь тест, потом код, который заставляет его пройти. Обратный порядок по сравнению с привычным “написал код → проверил вручную → может, добавил тест потом”.

Цикл red-green-refactor:

Red — пишешь тест на функциональность, которой ещё нет. Тест падает (код ещё не написан).
Green — пишешь минимальный код, чтобы тест прошёл. Не идеальный, просто рабочий.
Refactor — улучшаешь код (убираешь дублирование, делаешь чище), не меняя поведения — тесты должны остаться зелёными.

// 1. Red — тест написан первым, метода sum ещё нет
@Test
void shouldSumTwoNumbers() {
    assertEquals(5, new Calculator().sum(2, 3));   // ❌ не компилируется/падает
}

// 2. Green — минимальный код, чтобы тест прошёл
class Calculator {
    int sum(int a, int b) { return a + b; }   // ✅ тест зелёный
}

// 3. Refactor — улучшаем при необходимости, тест остаётся зелёным

Копнуть глубже

Зачем писать тест первым, а не после кода:

Тест заставляет думать об интерфейсе заранее — как код будет использоваться, до того как погрузишься в детали реализации.
Гарантия покрытия. Если писать тесты после — легко забыть протестировать какой-то случай. TDD заставляет описать ожидаемое поведение до того, как код существует.
Безопасный рефакторинг. Зелёные тесты — это страховка: можно менять реализацию, не боясь сломать поведение незаметно.

TDD — это не панацея. В реальности многие команды не следуют TDD строго на 100% задач — особенно когда экспериментируют с подходом и сама архитектура ещё неясна. Но даже частичное использование (на критичной бизнес-логике) даёт ощутимую пользу в виде уверенности при изменениях.

🎤 Закрыл тему, если можешь объяснить:

• цикл red-green-refactor;
• зачем писать тест до кода, а не после (если дошёл до 2-го слоя).