Что такое TDD

Что проверяют

Писал ли кандидат по этой схеме сам или пересказывает статью. Java-разработчика тут спрашивают про декомпозицию задачи, дисциплину маленьких шагов и про то, как он отличает тест на поведение от теста на реализацию.

Как отвечать

Цикл red-green-refactor: падающий тест на одно поведение, минимальный код до зелёного, затем рефакторинг при зелёных тестах. Инструменты называть конкретно: JUnit, AssertJ или встроенные проверки, Mockito для границ, а на уровне интеграции срезы контекста и Testcontainers для настоящей базы.

@Test
void totalOfEmptyCartIsZero() {
    assertThat(new Cart().total()).isEqualTo(Money.ZERO);
}

Принципы, которые ждут в ответе: один тест про одно правило; имя теста описывает правило, а не имя метода; шаги мелкие, обобщение приходит после второго и третьего примера; рефакторить нужно и код, и сами тесты; заглушками закрываются только границы системы, то есть сеть, база, время и очередь, а собственные значения и доменные объекты используются настоящими.

Сильный ответ честно называет, где подход ложится плохо: легаси без швов, куда сначала нужны характеризующие тесты; исследовательский код, который пишется, чтобы разобраться в задаче, и выбрасывается; задачи, у которых вся сложность в интеграции, а не в логике.

Где спотыкаются

Пишут тесты на реализацию: проверяют, что у заглушки вызвали такой-то метод столько-то раз. Любой рефакторинг ломает такие тесты, хотя поведение не изменилось, и команда постепенно перестаёт им доверять.

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

Заглушают всё подряд, включая то, что как раз и тестируют. Получается тест, который проверяет не логику, а собственную настройку заглушек: он зелёный при любой реализации и падает только при переименовании методов.