Есть ли веские доказательства окупаемости модульного тестирования?

127

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

Какие есть доказательства? Кто-нибудь действительно разработал одно и то же программное обеспечение двумя отдельными командами, одна из которых использовала модульное тестирование, а другая нет, и сравнила результаты? Я сомневаюсь в этом. Должен ли я просто оправдать это словами: «Поищи это в Интернете, все об этом говорят, так что, должно быть, это правильно»?

Где неопровержимые доказательства, которые убедят неспециалистов в том, что модульное тестирование стоит затраченных усилий?

вороной
источник

Ответы:

98

Да. Это ссылка на исследование по Boby Джорджа и Лори Уильямс в NCST и другим путем Nagappan и др. Я уверен, что есть еще Публикации доктора Вильямса о тестировании могут стать хорошей отправной точкой для их поиска.

[РЕДАКТИРОВАТЬ] В двух вышеупомянутых документах конкретно упоминается TDD и показано увеличение начального времени разработки на 15-35% после принятия TDD, но снижение на 40-90% дефектов до выпуска. Если вы не можете получить полнотекстовые версии, я предлагаю использовать Google Scholar, чтобы узнать, сможете ли вы найти общедоступную версию.

tvanfosson
источник
14
Первое исследование сравнивает Agile + TDD с проектами водопада, его результаты были бы более актуальными, если бы в нем сравнивались две agile-команды. Во втором исследовании упоминаются и другие исследования, в которых практически не было обнаружено качественного бонуса для проектов TDD. И когда вы сравниваете оценки руководства о необходимом дополнительном времени для TDD, это значительно выше для двух команд с большим опытом в предметной области, но при этом их охват тестированием на 20% ниже. Это подтверждает мой собственный опыт, я считаю, что уверенность намного важнее в системах, с которыми я еще не работал, а тестирование - препятствие для всего остального.
LearnCocos2D,
Ни одно из исследований не сравнивает сопоставимую модель процесса только с изменением тестметофологии. То есть время, потраченное на UT, на самом деле лучше потратить, например. системное тестирование. В его нынешнем виде это могло бы быть с тем же успехом «если мы будем тестировать умнее, это поможет».
Rune FS
1
Так что, если стоимость исправления ошибок после выпуска составляет 0,01% от общей суммы разработки? В таком случае TDD будет ужасной инвестицией. А если багов мало? Эти% s ничего не значат без контекста. Честно говоря, я еще не прочитал все исследование. Но в нынешнем виде ваш пост полезен (хорошие ссылки), но не отвечает на вопрос о рентабельности инвестиций, ИМО.
Instine
1
@Instine К счастью (?) Есть веские доказательства того, что это не так. Исправление ошибок после выпуска экспоненциально дороже, чем ошибки, обнаруженные на ранней стадии разработки (что и делает TDD). В этом контексте затраты на 0,01% от общего объема разработки для всех ошибок после выпуска кажутся маловероятными. (Подробнее см. Code Complete , в частности, Boehm & al. , «Понимание и контроль затрат на программное обеспечение», IEEE Trans Softw Eng (1988)).
Конрад Рудольф
Вероятно, стоит отметить, что в первом исследовании выборка состояла из 24 программистов (работающих в парах, то есть 12 команд). Я не уверен, какой будет статистически достоверный размер выборки, но он кажется низким. Может, кто-то еще знает?
Zachary Yates
29

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

Зачем?

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

Обучение фреймворку занимает очень мало времени.

Написание одного теста, всего одного, занимает очень мало времени.

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

Это все, что нужно. Никто не должен знать, что вы это делаете. Просто сделай это.

С. Лотт
источник
9
Счетчики bean-компонентов не могли отличить модульный тест от остальной части кода, если бы от этого зависела их жизнь. Я поддерживаю предложение просто сделать это. Однако есть одно предостережение: если вы не одиноки, вам нужно, чтобы ваши товарищи-разработчики приняли эту практику. В противном случае они непреднамеренно нарушат ваши тесты.
Thomas Eyde
Просто сделайте это и не говорите им, и продайте идею своим колледжам во время перерыва на кофе ;-)
Йохан
3
Потому что вас уволили бы, если бы вы постоянно не уложились в сроки?
Эндрю
3
@Neko: Модульные тесты не добавляют «накладных расходов». Они снижают общую рабочую нагрузку, предотвращая целый поток глупых ошибок. Работа не растет; он просто переходит от плохого кода к хорошим модульным тестам и хорошему коду.
S.Lott
1
Счетчики bean-компонентов хотят, чтобы их инженеры предоставили надежные решения проблем домена. Вы можете просто написать тесты как часть своего решения. Они даже не заметят. Если они спросят, вы можете просто сказать им, что тратите на него больше времени, чтобы убедиться, что он надежный и не требует переделки. Если вы ПРЕДЛАГАЕТЕ написать им модульные тесты, вы спрашиваете их одобрения в том, о чем они ничего не знают.
Yorkshireman
16

Я использую другой подход к этому:

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

Интересна идея обновления тестов. Сами тесты менять нечасто. У меня в 3 раза больше тестового кода по сравнению с производственным кодом, а тестовый код изменился очень мало. Однако это то, что позволяет мне спокойно спать по ночам и то, что позволяет мне сказать клиенту, что я уверен, что смогу реализовать функциональность Y без нарушения системы.

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

Вот где это окупается: 1) вы уверены в своем коде и 2) вы обнаруживаете проблемы раньше, чем в противном случае. У вас нет такого специалиста по контролю качества, который сказал бы: «Эй, вы не потрудились проверить границы функции xyz (), не так ли? Он не может найти эту ошибку, потому что вы нашли ее месяц назад. Это хорошо для ему хорошо для вас, хорошо для компании и хорошо для клиента.

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

itsmatt
источник
Мой специалист по контролю качества был довольно проницательным, но он не смотрел на код, но было легко сказать, что границы не проверялись.
itsmatt
Полностью согласен с тем, что модульное тестирование заставит вас больше думать о дизайне и правильности, а не о коде безрассудно
chakrit
7
Клиенты не платят нам за написание тестов. Опять же, они не платят нам за написание кода. Они платят нам за решение своих проблем, и, готов поспорить, они хотят, чтобы проблемы оставались решенными. Судя по свидетельствам, невероятно, что клиенты не хотят защищать свои инвестиции.
Thomas Eyde
10

Мы убедительно продемонстрировали, что можно писать дрянное программное обеспечение без модульного тестирования. Я считаю, что есть даже свидетельства того, что с помощью модульного тестирования существует дрянное программное обеспечение. Но дело не в этом.

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

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

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

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

Олаф Кок
источник
13
Слушайте, слышите :) Многие неопровержимые доказательства TDD также исходят от очень опытных команд, которые уже добивались хороших результатов без этого. TDD просто улучшили свои результаты, а не создавали их из воздуха. Настоящая рентабельность инвестиций - это нанять приличных программистов и позволить им решать, как что-то делать.
workmad3,
«Счетчики бобов должны определять, как должны работать технические специалисты?» -> все бизнес-решения сводятся к деньгам. Тем не менее, хороший ответ, +1
jcollum
@jcollum, но то, как вы выполняете свою работу, не имеет ничего общего с деньгами, и если вы хотите, чтобы один из них был подотчетен, вы позволяете им решать, КАК они делают то, ЧТО вы их просили
Rune FS
TDD - это не метод проектирования, это просто метод кодирования. blog.ploeh.dk/2010/12/22/TheTDDApostate Многие комментаторы не согласны с тем, что TDD включает рефакторинг (который является методом проектирования), но рефакторинг не подразумевает TDD. Можно выполнить рефакторинг без тестов, большой сложный рефакторинг в любом случае влияет на модульные тесты, т.е. тесты тоже нужно реорганизовать, поэтому они могут стать недействительными / ложно-зелеными; более простые рефакторинги не влияют на тесты, но риск ошибки ниже, потому что рефакторинг прост.
KolA 07
@KolA ну, учитывая, что спустя 10,5 лет после этого ответа, я мог бы сказать, что сегодня это немного более оборонительно, но все же: я не спорю, что TDD - единственный метод проектирования, который вам когда-либо понадобится, и Марк начинает с того, что хороший дизайнерский прием, прежде чем сделать вывод, что это совсем не так. Я бы ослабить его мнение и сказать , что это не должно быть только метод проектирования. Каждый код, который я когда- либо писал TDD, отличается от кода, без которого я писал. Я бы назвал это результатом дизайна. Я лучше всего работаю с доской, обсуждениями и другими инструментами в дополнение к TDD. Но спасибо за ссылку
Olaf Kock
6

Больше о TDD, чем строго модульном тестировании, вот ссылка на статью « Осуществление улучшения качества посредством разработки, управляемой тестированием: результаты и опыт четырех промышленных групп» , написанные Нагаппаном, Э. Майклом Максимилианом, Тирумалешем Бхатом и Лори Уильямс. документ, опубликованный группой Microsoft Empirical Software Engineering and Measurement (ESM) и уже упомянутый здесь.

Команда обнаружила, что команды TDD производили код, который на 60–90% лучше (с точки зрения плотности дефектов), чем команды, не использующие TDD. Однако командам TDD требовалось от 15% до 35% больше времени для завершения своих проектов.

philant
источник
5

Вот отличное и занимательное чтение о парне, меняющем компанию изнутри. Это не ограничивается TDD. http://jamesshore.com/Change-Diary/ Обратите внимание, что он довольно долго не уговаривал «счетчиков фасоли», а вместо этого использовал «партизанскую тактику».

Epaga
источник
ссылка выглядит интересной ... стоит проверить re: изменение рабочих процессов в организациях ...
nasty Pasty
5

Чтобы добавить больше информации к этим ответам, есть два ресурса для мета-анализа, которые могут помочь выяснить влияние производительности и качества на академическую и отраслевую подготовку:

Введение приглашенных редакторов: TDD - Искусство бесстрашного программирования [ ссылка ]

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

Таблица 1. Сводка избранных эмпирических исследований разработки через тестирование: участники отрасли *

https://www.computer.org/cms/Computer.org/dl/mags/so/2007/03/figures/s3024t1.gif

Таблица 2. Резюме избранных эмпирических исследований TDD: академические участники *

введите описание изображения здесь

Влияние разработки, основанной на тестировании, на внешнее качество и производительность: метаанализ [ ссылка ]

Аннотация:

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

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

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

Дариуш Возняк
источник
4

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

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

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

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

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

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

Начните с чего-нибудь настолько простого, что вы не заметите, что делаете это. При подготовке к марафону начните с ходьбы 9 метров и бегите 1 метр, повторите.

Jonke
источник
Итак, я должен просто сделать это? Это гарантированно сработает, и неважно, если со мной этого никто не сделает?
raven
Собственно, это тест Джоэла: joelonsoftware.com/articles/fog0000000043.html . Мне кажется, что у вас может быть больше проблем, чем отсутствие Нобелевской премии исследования по модульному тесту
Йонке,
4

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

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

Габриэле Д'Антона
источник
1
Об этом рассказывается в « Завершенном коде» Стива МакКоннелла - книге, которую вы, вероятно, захотите иметь на своей книжной полке по другим причинам.
Роберт Россни
Это не связано с методом тестирования, а с тем, когда в процессе сообщается об ошибке, и в дальнейшем было бы лучше потратить время на поиск ошибок в спецификациях, поскольку стоимость их исправления при их обнаружении при разработке сообщается в 1000 раз дороже ( фактор 10 на фазу разработки)
Rune FS
OTOH, если вы исправляете только проблемы, с которыми люди на самом деле сталкиваются в реальных жизненных ситуациях, вам, вероятно, придется исправлять гораздо меньше ошибок. Мне также не ясно, что исправление ошибок на более раннем этапе действительно дешевле, поскольку обнаружение ошибки в спецификации может потребовать гораздо больше усилий, чем обнаружение той же ошибки в реализации, а обнаружение ошибки является частью стоимости исправления. Это одна из тех вещей, в которые все просто верят, потому что это звучит самоочевидно, но я никогда не видел серьезного исследования, которое показало бы эффект.
LKM
0

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

Много месяцев назад я был новым выпускником, работающим над большим проектом VB6, и мне довелось написать большой объем кода хранимых процедур. В подсистеме, которую я писал, она составляла около 1/4 всей кодовой базы - около 13 000 LOC из 50 000 или около того.

Я написал набор модульных тестов для хранимых процедур, но модульное тестирование кода пользовательского интерфейса VB6 невозможно без таких инструментов, как Rational Robot; по крайней мере, тогда этого не было.

По статистике QA, во всей подсистеме возникло около 40 или 50 дефектов, два из которых возникли из хранимых процедур. Это один дефект на 6500 строк кода по сравнению с 1 дефектом на 1000-1200 или около того во всем фрагменте. Также имейте в виду, что около 2/3 кода VB6 было стандартным кодом для обработки ошибок и ведения журнала, идентичным для всех процедур.

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

ConcernedOfTunbridgeWells
источник