TDD / Испытывает слишком много накладных расходов / затрат на обслуживание?

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

Недавно у меня была дискуссия о выполнении TDD для переписывания продукта, где текущая команда не практикует модульное тестирование на каком-либо уровне и, вероятно, никогда не слышала о методике внедрения зависимостей или шаблонах тестирования / дизайне и т. Д. (Мы даже не получим на чистом коде).

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

Я могу понять, что TDD в команде, которая в настоящее время не имеет опыта тестирования, звучит не очень хорошо, но мой аргумент в этом случае заключается в том, что я могу преподавать свою практику окружающим, но, кроме того, я знаю, что TDD делает ЛУЧШЕ програмное обеспечение. Даже если бы я должен был производить программное обеспечение с использованием TDD и отбросить все тесты при передаче его команде по техническому обслуживанию, это, безусловно, будет лучшим подходом, чем вообще не использовать TDD с самого начала?

Меня сбили с толку, поскольку я упоминал, что делал TDD в большинстве проектов для команды, которая никогда не слышала об этом. Мысль об «интерфейсах» и странно выглядящих конструкторах DI отпугивает их ...

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

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

Вы не можете выиграть этот аргумент. Они делают это. К сожалению, у вас нет реальных фактов. Любой приведенный вами пример может быть оспорен.

Единственный способ подчеркнуть это - иметь код, который дешевле в обслуживании.

Кроме того, поскольку это интерфейсное приложение (не веб-приложение), добавлять тесты бессмысленно,

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

Однако, если приложение плохо спроектировано, интерфейс делает слишком много и его сложно протестировать. Это проблема дизайна, а не проблема тестирования.

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

Это тот же аргумент, что и выше.

Вы не можете выиграть спор. Так что не спорь.

«Я полностью отвечаю за переписывание этого продукта»

В таком случае,

1. Добавить тесты в любом случае. Но добавляйте тесты по мере продвижения. Не тратьте много времени на тестирование, написанное первым. Конвертировать немного. Попробуй немного. Конвертировать немного больше. Попробуй еще немного.

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

У меня был тот же аргумент при переписывании (с C ++ на Java), и я просто использовал тесты, даже если они сказали мне не делать этого.

Я развивался очень быстро. Я попросил конкретные примеры правильных результатов, которые они отправили в электронных таблицах. Я превратил электронные таблицы в unittest.TestCase (не сообщая их) и использовал их для тестирования.

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

Никто не должен знать подробно, почему вы успешны.

Просто будь успешным.

Вы можете только убедить таких людей (если вообще) с практической точки зрения, демонстрируя ценность TDD в реальной жизни. Например, взяв в качестве примера недавнюю ошибку и показывая, как построить модульный тест, который на 100% гарантирует, что эта ошибка больше никогда не появится. И затем, конечно, напишите еще дюжину модульных тестов, чтобы предотвратить появление целого класса подобных ошибок (и кто знает, может быть, даже обнаружив еще несколько неактивных ошибок в коде).

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

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

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

Скорее всего, именно поэтому они не заботятся о модульном тестировании.

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

PS. Я вижу еще один из ваших вопросов, где вы критикуете слои абстракции, а здесь вы критикуете отсутствие конструкторов DI! Подумайте об этом :)

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

Укажите, что поиск ошибки во время разработки стоит X, во время тестирования 10X и после развертывания 100X. Посмотрите, позволят ли они, по крайней мере, вам провести пилотный тест, в котором вы внедрили TDD в конкретном модуле, а затем проведите сравнение с другими модулями по мере их разработки, тестирования, развертывания и поддержки. При наличии достаточных данных вы сможете продемонстрировать, как меньше усилий было потрачено на создание кода в модуле TDD. Удачи.

Да, поддержание тестов - это бремя. Обновление их, обновление ваших тестовых данных: все это отнимает ваше время.

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

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