В чем необходимость TDD?

Question

[Kirill Popolov]

Осваиваю книгу Ruby on Rail Tutorial.

На каждый чих приходится как минимум по одному тесту. К примеру проверка на наличие в заголовке некоторой фразы. Сначала я пишу тест, проверяю, что он провальный, затем вставляю фразу в заголовок, затем снова тестирую. В чем суть?

Чем хуже написать участок кода, а затем тестировать его, либо не тестировать вовсе, если требуемое поведение реализовано?

Answer 1

[Yuri Morozov]

Проще всего рассматривать это так: тестами ты сам себе ТЗ пишешь.
Я хочу такой-то функционал (написал тест), и пока этого нет (тест провалился).

Если не проверять тесты на предварительную провальность, пришлось бы еще тесты на тесты писать, поскольку есть шанс написать тест, который всегда проходить будет.

По поводу "поведение реализовано": никто не гарантирует, что в процессе последующей разработки или (обновления фреймворка) поведение внезапно не отвалится, так что даже если сейчас оно работает - неплохо бы за этим следить.

Comments

[Kirill Popolov]

А если у меня уже есть ТЗ? Сформированное по пунктам чего я хочу от приложения. Зачем его описывать в тестах? Я могу понять тестирование работы с базой данных - это действительно удобно, но мне удобнее писать тест ПОСЛЕ, а не до. Так, мне кажется, нагляднее. Если пытаться писать тесты до, то можно упустить что-то важное.

[DancingOnWater]

Тест после писать будет ЛЕНЬ.

[Kirill Popolov]

Писать тест до еще более лень. Особенно когда тестируется что-то очевидное, что будет заметно при загрузке страницы.

[Yuri Morozov]

@ezhikov как я уже писал выше, никто не гарантирует, что при дальнейшем росте приложения "что-то очевидное" внезапно не отвалится.

[Kirill Popolov]

Вроде начинаю понимать. Спасибо.

Answer 2

[Vampiro]

Тесты начинаешь "понимать" когда количество "проверяемых на глаз" страниц после каждой правки переваливает за 7-10 (+под разными логинами). Тогда действительно становится более лениво "ползать по сайту", чем "написать тест". Для трех-страничной хоумпейдж не актуальны, в остальных случаях "мастхев"

Answer 3

[green_turtle]

TDD - это способ разработки прежде всего. Это больше относится к архитектуре и дизайну приложений. Когда вы пишите тесты - вы придумаваете архитектуру своего приложения: модель, её связи и т.п. Взглянув на тесты вы должны понять что и как делает ваше приложение.
Грубый пример: вы хотите написать приложение которое пересылает деньги с одного аккаунта на другой. Начав писать, к примеру, тест "Должна быть ошибка при отрицательном балансе первого аккаунта", вы пока не имеете никакой модели (классов) вовсе. Поэтому вы начинаете продумывать как всё будет устроено прямо в тесте: мне нужен класс AccountService для того чтобы делать переводы, класс Account, который содержит информацию о счёте и т.д. Написав логику, конечно тест будет "красным" т.к. вы ещё не написали таких классов, НО теперь самое время сделать так, чтобы тест стал "зелёным" - написать эти классы и лишь ту бизнес-логику, которую проверяет тест.

Answer 4

[afiskon]

Тут есть немного про суть модульных тестов и TDD.