Тест-ориентированная разработка "Барьеры для входа"?

Question

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

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

Мысли / чувства приветствуются.

Спасибо

РЕДАКТИРОВАТЬ - кто-нибудь знает какие-либо громкие цитаты людей, выступающих за TDD? Хотелось бы увидеть, как высоко он поднимается вверх по цепочке. Приветствия.

Answer 1

Некоторые барьеры включают в себя:

1. Существующая кодовая база, которая не подходит для модульного тестирования.
2. Проблемная область, которую сложно провести модульное тестирование, например, работа с графическим интерфейсом или интеграция со сторонними системами.
3. Восприятие проблем интеграции по отношению к проблемам устройства (другими словами, если оно не работает от конца к концу, оно ничего не делает, так какой смысл тестировать устройство).
4. Менталитет, который хочет разрабатывать заранее и иметь четкую конструкцию системы, а не тест-драйв дизайн
5. Политическая культура, в которой дизайн выполняется другим человеком / группой, а не разработчиком, и этот дизайн не подходит для юнит-теста.
6. Невозможность преодолеть тот факт, что TDD не о тестировании на соответствие (аргументы типа «тот, кто пишет тесты, не должен быть тем, кто его кодирует, они будут слишком снисходительны к себе» и такие варианты) .
7. Это не так, как они кодировали до сих пор, поэтому сдвиг сложнее.
8. Иногда определенный тест может быть трудно настроить, поэтому метод будет отменен, потому что он "чувствует" медленнее.
9. Требования к проектированию, которые не поддаются совершенствованию проектирования вообще или вообще (думаю, что управляющее программное обеспечение АЭС или другие системы были фактическими жизнями, зависит от их правильного функционирования).
10. Если все не запускают тест перед проверкой кода, тесты начинают часто прерываться по неправильным причинам (то есть изменилось предполагаемое поведение кода, но тест не выдержал, поэтому тест неверен, не код), поэтому они могут быть восприняты как перетаскивание.

Answer 2

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

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

Обратите внимание, что это ни в коем случае не является отрицательным аспектом TDD; Я просто говорю, что фронтальная загрузка МОЖЕТ рассматриваться как "барьер для входа". Лично я, как программист, скажу, что окупаемость инвестиций более чем стоит усилий, и я думаю, что большинство опытных менеджеров по разработке тоже.

Answer 3

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

Прежде, чем я попробовал TDD, я бы создал класс, скажем Employee, затем я бы заглушил такие вещи, как FirstName, LastName, Email и т. Д. Затем я бы написал некоторую логику и забыл, что пропустил несколько полей или что-то еще. А до того, как я узнал об этом, у меня был довольно сложный класс, не зная, были ли когда-нибудь необходимы эти поля.

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

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

Несколько причин, почему это не удалось до сих пор, где я работаю:

1. Большинство проектов, над которыми мы работаем, - это старые приложения. Не до .NET, но .NET 2.0, а в некоторых случаях .NET 1.0.
2. Некоторые из этих проектов не очень хорошо продуманы, либо потому, что технологии не было в 1.0, либо она была построена быстро, потому что им нужно что-то СЕЙЧАС ..
3. Как указал Джон, некоторые вещи все еще являются PIA (болью в - ***) для модульного тестирования, пользовательского интерфейса, базы данных и т. Д.
4. Дорогие инструменты. Если вам разрешено использовать только инструменты Microsoft, стоит сделать это «правильным способом». Мы используем Resharper, так что это действительно не проблема.
5. Время. Я в команде из трех парней, поддерживающих отдел из 30 человек. Нас считают накладными, и многие наши разработки состоят из систем сопряжения вместе

Answer 4

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

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

Answer 5

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

Answer 6

Несколько недель назад я написал длинную статью об этом: " Почему я пишу тесты в первую очередь ".

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

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

Я считаю себя опытным автором тестов, но не всегда могу думать с точки зрения тестов. Некоторые проблемы не подходят для этого, или, по крайней мере, моя голова не оборачивается этим несколько дней. А некоторые типы кода (например, пользовательский интерфейс и код на стороне клиента) не всегда подходят для написания тестов.

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

Answer 7

Я, конечно, видел много сопротивления. Барьеры, с которыми я столкнулся:

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

Answer 8

Да, основной барьер для входа в вашу голову или в голову других программистов.

Сначала вы не знаете, что использовать в своих тестах.

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

Когда вы начинаете «получать это», становится немного трудно понять, где прекратить писать тесты. Вы должны помнить, что тесты ничего не доказывают, поэтому вы просто не можете написать тесты для всех случаев, вы должны выбрать самые полезные ... и это уже много!