Есть ли убедительные доказательства ROI модульного тестирования?
модульное тестирование звучит здорово для меня, но я не уверен, что должен тратить время на его изучение, если я не могу убедить других, что это имеет значительную ценность. Я должен убедить других программистов и, что более важно, счетчики бобов в управлении, что все дополнительное время тратится на изучение структуры тестирования, написание тестов, их обновление и т. д.. заплатит за себя, а потом и за некоторых.
какие есть доказательства? Кто-то создал такое же программное обеспечение две отдельные команды, одна из которых использует модульное тестирование, а другая нет, и сравнивают результаты? Я сомневаюсь в этом. Я просто должен оправдать это: "посмотрите в интернете, все говорят об этом, так что это должно быть правильно"?
где твердые доказательства, которые убедят непрофессионалов, что модульное тестирование стоит усилий?
11 ответов:
да. Это же ссылке к исследованию Боби Джорджа и Лори Уильямс в NCST и A другое по Nagappan et al. Я уверен, что есть и другие. Доктор Уильямс публикации при тестировании может обеспечить хорошую отправную точку для их поиска.
[EDIT] две вышеприведенные статьи специально ссылаются на TDD и показывают увеличение начального времени разработки на 15-35% после принятия TDD, но уменьшение дефектов перед выпуском на 40-90%. Если вы не можете добраться до полнотекстовые версии, я предлагаю использовать Google Scholar чтобы увидеть, если вы можете найти общедоступную версию.
" Я должен передать другим программистам и, что более важно, счетчикам бобов в управлении, что все дополнительное время тратится на изучение структуры тестирования, написание тестов, их обновление и т. д.. заплатит за себя, а потом и за некоторых."
Почему?
Почему бы просто не сделать это тихо и незаметно. Вы не должны делать все это сразу. Вы можете сделать это на маленькие кусочки.
в рамках обучения занимает очень мало время.
написание одного теста, всего одного, занимает очень мало времени.
без модульного тестирования, у вас есть некоторая уверенность в вашем программном обеспечении. С одним модульным тестом у вас все еще есть уверенность, а также доказательство того, что хотя бы один тест проходит.
Это все, что нужно. Никто не должен знать, что ты это делаешь. Просто сделай это.
У меня другой подход к этому:
какие у вас есть гарантии, что ваш код верен? Или что он не нарушает предположение X, когда кто-то из вашей команды меняет func1()? Без модульных тестов, которые держат вас "честными", я не уверен, что у вас есть большая уверенность.
концепция сохранения тесты обновленный интересно. Сами тесты не часто приходится менять. У меня есть 3x тестовый код по сравнению с производственным кодом, и тестовый код был изменен очень мало. Это, однако, то, что позволяет мне хорошо спать по ночам и то, что позволяет мне сказать клиенту, что у меня есть уверенность, что я могу реализовать функциональность Y, не нарушая систему.
возможно, в академических кругах есть доказательства, но я никогда не работал нигде в коммерческом мире, где кто-то заплатил бы за такой тест. Я могу сказать вам, однако, что он хорошо работал для меня, потребовалось мало времени, чтобы привыкнуть к тестовой структуре и написание теста сделало меня действительно подумайте о моих требованиях и дизайне, гораздо больше, чем я когда-либо делал, работая над командами, которые не писали никаких тестов.
вот где он платит за себя: 1) у вас есть уверенность в своем коде и 2) вы ловите проблемы раньше, чем в противном случае. У вас нет парня QA, который говорит: "Эй, вы не беспокоились о границах-проверка функции xyz (), не так ли? он не удается найти эту ошибку, потому что вы нашли его месяц назад. Это хорошо для него, хорошо для вас, хорошо для компании и для клиента.
ясно, что это анекдотический, но он творил чудеса для меня. Не уверен, что я могу предоставить вам электронные таблицы, но мой клиент доволен, и это конечная цель.
мы продемонстрировали с твердыми доказательствами, что можно писать дерьмовое программное обеспечение без модульного тестирования. Я считаю, что есть даже доказательства для дерьмового программного обеспечения с модульным тестированием. Но дело не в этом.
модульное тестирование или разработка с тестовым управлением (TDD) - это метод проектирования, а не метод тестирования. Код, написанный тестовым приводом, выглядит совершенно иначе, чем код, которого нет.
хотя это не ваш вопрос, мне интересно, действительно ли это самый простой способ идти по дороге и отвечать на вопросы (и приводить доказательства, которые могут быть оспорены другими докладами), которые могут быть заданы неправильно. Даже если вы найдете веские доказательства для вашего дела - кто-то другой может найти веские доказательства против.
это дело счетоводам, чтобы определить, как технические люди должны работать? Они предоставляют самые дешевые инструменты во всех случаях, потому что они считают, что вам не нужны более дорогие?
этот аргумент либо выигран на основе доверие (одна из фундаментальных ценностей гибких команд) либо теряется на основе ролевой мощи победившей стороны. Даже если сторонники TDD выиграют, основываясь на силе роли, я бы посчитал это потерянным.
больше о TDD, чем строго модульное тестирование, вот ссылка на реализация повышения качества за счет тестовой разработки: результаты и опыт четырех промышленных команд бумага, по Nagappan, Е. Майкл Максимильен, Thirumalesh Бхат, и Лори Уильямс. статья опубликована Microsoft эмпирическая Программная инженерия и измерение (ESM) группа и уже упоминалось здесь.
команда обнаружила, что команды TDD создали код, который между 60% и 90% процентов лучше (с точки зрения плотности дефектов), чем команды без TDD. команды TDD заняли от 15% до 35% больше времени, чтобы завершить свои проекты.
вот отличное и интересное чтение о парне, меняющем свою компанию изнутри. Это не ограничивается TDD. http://jamesshore.com/Change-Diary/ Обратите внимание, что он довольно долго не убеждал "бобовые счетчики" и вместо этого делал "партизанскую тактику".
Ну, есть некоторые крупные компании, которые требуют от вас использовать модульное тестирование, но если вы небольшая компания, Зачем имитировать большие?
для меня, когда я начал с модульного тестирования , много лет назад,(сегодня мы в основном используем поведение модель) это было потому, что я не мог контролировать весь путь в одном приложении.
Я привык к нижнему первому программированию и REPL, поэтому, когда я получил модульный тест (один тест для каждой функции), это было похоже на возвращение REPL к языкам что где очень много компиляции. Это вернуло удовольствие к каждой строке кода, которую я написал. Я чувствовал Бога. Мне понравилось. Мне не нужен отчет, чтобы сказать мне, что я начал писать лучший код быстрее. Моему боссу не нужен был отчет, чтобы заметить это, потому что мы, где делали сумасшедшие вещи, мы внезапно никогда не пропускали крайний срок. Моему боссу не нужен был отчет, чтобы заметить, что количество "простых" ошибок падает от (до многих) почти до нуля из-за этой очень странной вещи написания непродуктивного кода.
Как другой плакат уже написал, что вы не используете TDD для тестирования (проверки). Вы пишете его, чтобы захватить спецификацию, поведение того, что ваш блок(объект, модуль, функция, класс, сервер, кластер) работает.
есть много неудач и историй успеха перехода на другую модель разработки программного обеспечения во многих компаниях.
Я просто начал использовать его всякий раз, когда у меня было что-то новое, чтобы написать. Есть старая поговорка, которую мне трудно перевести английский, но:
начните с чего-то настолько простого, что вы не замечаете, что делаете это. При подготовке к марафону начните с ходьбы 9 метров и бегите 1 метр, повторяю.
просто чтобы добавить дополнительную информацию к этим ответам, есть два ресурса мета-анализа, которые могут помочь выяснить влияние производительности и качества на академический и отраслевой фон:
введение гостевых редакторов: TDD-искусство бесстрашного программирования [ссылке]
все исследователи, похоже, согласны с тем, что TDD способствует лучшей фокусировке задач и тестовое покрытие. Сам факт большего количества тестов не обязательно означает, что качество программного обеспечения будь лучше, но повыше тем не менее, внимание программистов к тестовому дизайну обнадеживает. Если мы посмотреть тестирование как выборку очень большой популяции потенциала поведение, больше тестов означает более тщательную выборку. В той мере, в какой каждый тест может найти важную проблему, которую никто из других не может найти, тесты полезны, особенно если вы можете запустить их дешево.
Таблица 1. Резюме отдельных эмпирических исследований тест-драйва развитие промышленности участники*
Таблица 2. Резюме отдельных эмпирических исследований TDD: академический участники*
влияние тестовой разработки на внешнее качество и производительность: метаанализ [ссылке]
Аннотация:
в данной статье представлен систематический метаанализ 27 исследований, которые расследование влияние тест-ориентированной разработки (TDD) на внешние факторы качество и производительность кода.
результаты показывают, что в целом TDD оказывает небольшое положительное влияние на качество, но практически не оказывает заметного влияния на производительность. Тем не менее, анализ подгрупп имеет обнаружено как улучшение качества, так и снижение производительности гораздо больше в промышленных исследованиях по сравнению с академическими исследованиями. Большее падение производительности было обнаружено в исследованиях, где разница в тесте усилия между TDD и контрольной группой процесс был значительным. Большее улучшение качества найдено в академических исследованиях, когда разница в тестовых усилиях составляет существенно; однако, никакое заключение не смогло быть выведено относительно промышленные исследования из-за отсутствия данных.
и, наконец, влияние опыт разработчика и размер задачи в качестве переменных модератора был исследовано и статистически значимая положительная корреляция найдено между размером задачи и величиной улучшения в качество.
есть статистика, которая доказывает, что исправление ошибки, найденной в тесте unit/integration, стоит во много раз меньше, чем исправление, когда оно находится в живой системе (они основаны на мониторинге тысяч реальных проектов).
Edit: например, как было указано, книга"Код" доклады о таких исследованиях (пункт 20.3, "относительная эффективность методов обеспечения качества"). Но есть и частные исследования в области консалтинга, которые доказывают, что как что ж.
Если вас также интересуют доказательства против модульного тестирования, вот одна хорошо исследованная и продуманная статья:
почему большинство модульных тестов-это отходы Джеймса О Коплиена (lean and agile guru)
У меня есть один набор точек данных для этого - из опыта, который продал меня на модульных тестах.
много лун назад я был выпускник работает над большим проектом VB6 и имел возможность написать большой объем кода хранимой процедуры. Из подсистемы, которую я писал, она составляла около 1/4 всей базы кода-около 13 000 LOC из 50K или около того.
Я написал набор модульных тестов для хранимых процедур, но модульное тестирование кода VB6 UI на самом деле невозможно без такие инструменты, как Rational Robot; по крайней мере, тогда этого не было.
статистика от QA на части состояла в том, что около 40 или 50 дефектов были подняты на всей подсистеме, из которых два возникла из хранимых процедур. Это один дефект на 6,500 строк кода против 1 на 1000-1200 или около того по всей части. Имейте в виду также, что около 2/3 кода VB6 был шаблонным кодом для обработки ошибок и ведения журнала, идентичным по всему все процедуры.
без слишком много handwaving вы можете приписать хотя бы улучшение порядка величины в тарифах дефекта к испытанию блока.