Есть ли области, где TDD обеспечивает высокую рентабельность инвестиций, и другие области, где ROI настолько низок, что не стоит следовать? [закрыто]

Тестовая разработка. Я понимаю, нравится.

Но написание тестов требует накладных расходов. Таким образом, следует ли использовать TDD повсеместно во всей кодовой базе или есть области, где TDD обеспечивает высокий ROI, и другие области, где ROI настолько низок, что его не стоит использовать.

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

Приложения, над которыми я недавно работал, были управляемыми данными веб-приложениями, построенными на основе архитектуры Gui-> Presenter-> BusinessLogic-> Data Access Layer. Мой уровень доступа к данным тестируется, как никто другой. Уровень бизнес-логики довольно хорошо протестирован. Презентаторы тестируются только в более стабильных областях, а графический интерфейс пользователя, который меняется ежечасно, практически не тестируется.

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

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

Например, в зависимости от вашего языка / технологии тестирование пользовательского интерфейса может быть нецелесообразным или даже неосуществимым. Многие тесты, вероятно, будут полагаться на то, что видит пользователь, и не могут быть автоматизированы. Как бы вы проверили, что метод генерации капчи создает изображение, которое, например, может прочитать человек?

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

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

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

Для меня TDD не накладные расходы. Это просто способ, которым я пишу код. Почему вы говорите, что написание теста "накладные расходы"? Это просто часть процесса. Моя точка зрения заключается в том, что отладка - это накладные расходы, и это действие, которое я фактически прекратил, когда начал TDD-инжиниринг. До TDD отладка была неотъемлемой частью моего процесса написания программного обеспечения.

Я думаю, что отказ от отладки для написания тестов - очень хорошая сделка.

Одно из мест, где TDD действительно отстой, - это тестирование представлений в приложении MVC.

Поскольку вы тестируете функцию, которая возвращает толстую строку html, вы застреваете, разбираясь с html, просто чтобы убедиться, что все получилось. Более того, это может стать кошмаром ремонтопригодности. Однажды вы перемещаете флажок и kaboom, ваш тест не пройден.

Мне нравится TDD для многих моих испытаний, но это не единственный инструмент в поясе программистов.