Зачем TDD?
Как программист может прийти к TDD и при этом извлечь пользу?
TDD (Test Driven Development) — это “разработка через тестирование”, метод придуманный и описанный Кентом Беком.
Так вот, допустим я программист, слышал что-то хорошее про TDD.
Как я могу понять, нужно ли мне изучать TDD, и если нужно, то зачем?
Можно попробовать ответить на этот вопрос, проследив путь программиста, который уже изучил TDD и извлёк из него пользу.
Эволюция программиста в TDD
Я представляю себе такой сценарий.
1. Разработчик пишет без тестов. Доволен.
2. Разработчик начинает страдать от того что код ломается.
3. Начинает писать тесты. Код ломается реже. Доволен.
4. Продолжает писать тесты. Начинает страдать от того что иногда тесты “не пишутся” или с ними тяжело.
5. Ищет решение. Находит TDD.
6. Пробует TDD. Не получается.
7. Практикует TDD ещё и ещё, пока наконец не начинает получаться.
8. Приходит просветление, о том как писать тесты и писать тестируемый код. “Вкурил TDD”.
9. Начинает писать только тестируемый код, потому что это становится привычкой и вообще непонятно как он мог раньше писать по-другому.
10. Иногда покрывает свой код тестами, иногда пишет по TDD.
11. Но в большей части пишет без тестов, так как для тестируемого кода тесты всегда легко добавить позже, когда они понадобятся.
12. PROFIT
Вывод
“Не созревшие” в таком сценарии, это те кто не дошёл до этапа 4 или недостаточно на нём настрадался, чтобы понять что “что-то здесь не так”.
Если вы “боретесь” с тестами, то возможно вам стоит взглянуть на TDD. Если же у вас всё в порядке и проблем нет — TDD вам ни к чему.
Бонус
У Кента Бека есть книга по TDD — рекомендую начать изучение с неё.
Обложку книги вы видите в начале статьи. Я прочёл её, книга небольшая, заинтересованный человек быстро её осилит.
А пока вы ждёте свою книгу, можете посмотреть видео от Роберта Мартина, который чтобы понять и освоить TDD лично приезжал в гости к Кенту Беку.
Зачем писать сначала тесты, потом код: https://www.youtube.com/watch?v=GvAzrC6-spQ
Демонстрация TDD: https://www.youtube.com/watch?v=58jGpV2Cg50&t=2628s
Всё видео на английском.
Бонус 2. Как доказать работу кода без тестов?
Мне задали такой вопрос.
Как разраб, “просветлевший” до пункта 11, доказывает работоспособность своего кода?
Говорит “мамой клянусь, катите уже на прод”?
Краткий ответ: он пишет код так, чтобы его работоспособность не требовалось доказывать.
Подробный ответ:
Почему нам вообще нужно доказывать работоспособность кода?
Нужно ли доказывать, например, что
<?php echo 'Hello world'; ?>
выведет строку “Hello world”?
Нет, не нужно. Но другой код — нужно. А почему?
Какая разница между тем кодом который доказательства не требует и тем который требует?
Не требуется доказывать код, который очевиден.
Если он очень прост, понятен с первого взгляда и его результат не вызывает сомнений — мы уже знаем, как он отработает.
Мы уверены в этом, потому что понимаем его от и до, и он помещается в нашей голове. Мы можем быть 100% уверены в результате.
Такой очевидный код не требует тестов, в силу своей очевидности.
Отсюда вывод: разработчик, желающий писать поменьше тестов, вынужден писать только очевидный, тривиальный, супер простой код.
Это требует развития навыка и опыта, но если задаться такой целью то можно этому научиться.
Также в достижении простого и понятного кода помогут принципы “чистого кода” и “чистой архитектуры” Роберта Мартина. А свободно переплавлять код из одной формы в другую, более простую поможет Мартин Фаулер с “рефакторингом”.
Когда навык написания супер простого кода развит, то почти весь написанный код тестов не требует.
Нужны ли нам тогда вообще тесты?
Некоторый код, от 1% до 5%, всё же потребуется покрыть тестами, так как некоторые задачи по своей сути содержат такое количество комбинаций выполнения что трудно всё заранее представить в голове.
Фёдор привёл отличный пример с форматтерами чисел, а я приведу из жизни пример последнего юнит-теста который писал: покрыл тестами хелпер который занимается вычислениями даты и времени и преобразованием в нужный формат.
Предвосхищая вопросы “нельзя ли взять готовое” — нет, нельзя, в “готовом” не учитываются нюансы форматов и соглашений конкретного проекта, логики самого приложения.
Приходим в итоге к такому разделению: везде пишем тестируемый и очень простой код без тестов, а в 1%-5% ещё и покрываем код тестами.
Плюсы:
-
Код пишется быстрее
-
Тестов мало, их легче поддерживать
Минусы:
- Такого уровня очень трудно достичь )