Попытка завоевать доверие в преимуществах TDD

Я просто купил Искусство Поблочного тестирования из Amazon. Я довольно серьезно отношусь к пониманию TDD, поэтому пребывайте в уверенности, что это - подлинный вопрос.

Но я чувствую, что постоянно нахожусь на грани нахождения, что выравнивание разочаровывается в нем.

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

1. TDD для сокращения ошибок

Это часто процитированное сообщение в блоге говорит, что модульные тесты являются средствами проектирования а не для ловли ошибок:

По моему опыту, модульные тесты не являются эффективным способом найти ошибки или обнаружить регрессии.

...

TDD является устойчивым способом разработать компоненты программного обеспечения (“единицы”) в интерактивном режиме так, чтобы их поведение было указано через модульные тесты. Это - все!

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

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

2. TDD как парадигма дизайна

Это - вероятно, большое. TDD является парадигмой дизайна, которая помогает Вам (или вынуждает Вас) сделать Ваш код более компонуемым.

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

Если Вы запустите с очень модульного функционального проекта и затем тщательно добавите состояние и IO к Вашему коду по мере необходимости, то Вы закончите с теми же шаблонами, которые поощряет TDD.

Например, для выполнения бизнес-логики на базе данных, код IO мог быть изолирован в функции, которая делает "одноместные" задачи доступа к базе данных и передачи его в как аргумент функции, ответственной за бизнес-логику. Это было бы функциональным способом сделать это.

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

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

3. TDD как документация

TDD, как говорят, служит документацией, но это только служит документацией для коллег; потребитель все еще требует текстовой документации.

Конечно, метод TDD мог служить основанием для примера кода, но тесты обычно содержат определенную степень насмешек, которые не должны быть в примере кода и обычно довольно изобретаются так, чтобы они могли быть оценены для равенства против ожидаемого результата.

Хороший модульный тест опишет в его сигнатуре метода точное поведение, это проверяется, и тест проверит не больше и не меньше, чем то поведение.

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

4. TDD для регрессионного тестирования

Это упоминается в том сообщении выше, что TDD не слишком полезен для обнаружения регрессий. Это, конечно, потому что неочевидные пограничные случаи - те, которые всегда портят, когда Вы изменяете некоторый код.

То, что могло бы также быть должно отметить по той теме, - то, что возможности хороши, что большая часть Вашего кода собирается остаться тем же в течение довольно долгого времени. Так, разве не имело бы большего смысла писать модульные тесты по мере необходимости, каждый раз, когда код изменяется, сохраняя старый код и сравнивая его результаты с новой функцией?