Для тех, кто не знаком, с методологией TDD, советую предварительно ознакомится с материалами: отличная статья про суть подхода, моя статья с небольшим практическим примером

Эта статья, в формате небольших тезисов, нацелена на открытие дискуссии на тему "Test Driven Development" – методологии разработки через тестирование. На моем текущем месте работы существует несколько мнений: начиная от полного принятия и стремления(к tdd), как к идеальному инструменту написания рабочего и лаконичного кода, вплоть до полного отвержения: TDD не работает, убивает время разработчиков, увеличивая при этом time-to-market.

К каждому тезису, которые я выделил, я буду оставлять свой комментарий, стараясь быть объективным и не транслировать какую-либо позицию.

Жду ваших комментариев, уверен, что во многом я могу быть не прав.

Рассмотрим основные аргументы ЗА:

TDD ведёт к увеличению процента покрытия кода тестами

Это действительно, факт, и с ним сложно спорить. Методология подразумевает написание тестов ДО написания кода, поэтому процент покрытия такого кода скорее всего будет стремиться к 100%.

TDD дает разработчикам большую уверенность в надежности и функциональности кода

Действительно, такое ощущение часто возникает, однако это скользкая тема. Само по себе наличие каких-либо тестов, как я выяснил на практике, не гарантирует ровным счетом ничего.

TDD избавляет разработчиков от страха внесения изменений в код

В целом тезис – продолжение предыдущего. Может все-таки стоит хоть немного бояться?) Страх иногда штука полезная.

Но оговорка: если твои тесты отменного качества, то несомненно. Если вы можете рассчитывать на тесты на все 100%, то тут даже и думать нечего, бегом рефакторить все налево и направо, и функционала нового побольше!

TDD подталкивает разработчиков к более прагматичным решениям

Я знаю N-ое количество разработчиков, которых в целом невозможно подтолкнуть к прагматичным решениям, поэтому этот тезис работает далеко не на всех. (А зачастую, те, кто и так склонен к глубокому анализу и прагматичным решениям, могут записывать это в преимущества TDD)

TDD позволяет разработчику быстро получить обратную связь от изменений в коде

Опять-таки, в идеальном мире – да. Но в реальном мире, у вас просто могут быть плохие тесты, которые не позволяют получить обратную связь в тех местах, где она действительно нужна.

TDD позволяет разработчику сосредоточиться на поставленной задаче

Опять же, факт. Что бы написать, пусть даже и плохой, тест, и впоследствии написать код, который проходит этот тест, необходимо сосредоточится. Хотя я не помню ни дня, когда я решал какую-либо задачу, не сосредоточившись на ней (пусть и ненадолго, но такой этап всегда присутствует)

TDD способствует четкому пониманию требований до начала написания кода

Да, абсолютно, но с оговоркой) Тех требований, которые показались тебе понятными. Система сыпется полностью, если требования неправильно донесли, тз было прочтено не в той формулировке, юзеркейсы оказались неверными – все это полностью уничтожает весь вклад TDD в разработку.

Я также не уверен, что на нашей планете существуют крупные проекты, где все требования были ясны с самого начала, и вам, как разработчику были представлены гарантии того, что эти требования не изменятся.

TDD = документированный код

Грамотные тесты достаточно четко документируют происходящее в коде, отвечая на вопрос: а что реально должно тут происходить? Огромное количество тестов, с которыми сталкивался я, не были в состоянии ответить ни на подобный, ни на прочего рода вопросы.

Рассмотрим основные аргументы ПРОТИВ:

TDD отнимает время

Действительно, с этим фактом не спорит никто, ни сторонники, ни противники TDD. Разброс прироста к длительности процесса разработки составляет 10-35%, в зависимости от квалификации и опыта команды.

TDD не гарантирует качество тестов

Отмечу, что, по сути, не существует такой методологии, которая могла бы гарантировать их качество. Мы можем только стремиться к этому, улучшая процент покрытия кода с использованием, например, мутационного тестирования. Тык

TDD ставит перед разработчиком нереалистичные цели

Позволю цитату:

«в реальной жизни фичи устроены немного сложнее, чем «функция X должна принять имя и вывести приветствие с этим именем». Часто требования к продукту меняются посреди работы или вы вдруг осознаёте, что фича не может работать согласно требованиям. Или вы изначально всё не так поняли, и вам нужно начинать работу с нуля» - тык

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

Изначальные требования могут быть поняты или сформулированы неверно

Да, сто процентов, такое может быть. Я уже озвучивал такую проблему выше, в противовес «четкому пониманию требований до начала написания кода»

Тесты необходимо поддерживать при изменении требований

Я думаю, каждому, кто работал на крупных проектах, приходилось видеть unit тесты низкого качества. Мало кто думает над парадигмой гибкости и переиспользуемости кода, при их написании, в результате чего тесты превращаются в полотно копипаста, которые при изменении поведений системы легче переписать с нуля, чем отрефакторить. Поддерживать тестовую базу возможно лишь при грамотном подходе к ее созданию, чего TDD не гарантирует.  

TDD зависит от конкретного разработчика

Действительно, сложно спорить, что если разработчик размышляет, планирует и умеет писать хороший код, то он сделает это и без TDD.

Заставь дурака богу молиться – он себе и лоб расшибет. Тот, кто пишет код бездумно, лишь засорит проект ненужными, не проверяющими ничего тестами, что в последствии будет лишь тормозить разработку.

В умелых руках TDD превращается в мощный инструмент, я лично знаю очень хороших разработчиков, для которых эта методология – способ сосредоточится и обдумать предстоящие изменения. При этом я знаю не меньшее количество профессионалов, отказавшихся от TDD, и пишущих при этом качественный код.

На этом, наверное, все. Вывода не будет, решайте все сами.

А как вы относитесь к TDD?

Источники:

• https://habr.com/ru/articles/334394/ -мутационное тестирование на примере php

• https://habr.com/ru/companies/otus/articles/580772/ - мутационное тестирование в java

• https://en.wikipedia.org/wiki/Test-driven_development - TDD, википедия

• https://fortegrp.com/insights/test-driven-development-benefits/ - про TDD в целом

• https://www.geeksforgeeks.org/advantages-and-disadvantages-of-test-driven-development-tdd/ - плюсы и минусы TDD

• https://tproger.ru/translations/test-driven-development-is-dumb - яркий пример статьи против TDD

• https://habr.com/ru/companies/ruvds/articles/450316/ - яркий пример статьи в пользу TDD