Ответ 1

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

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

Ответ 2

"Мне нужно конкретизировать других программистов и, что более важно, bean -counters в управлении, что все дополнительное время, потраченное на изучение структуры тестирования, написание тестов, обновление их и т.д., будет платить за себя, а затем некоторые."

Почему?

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Тестирование единиц или тестирование (TDD) - это метод проектирования, а не метод тестирования. Код, написанный на основе теста, полностью отличается от кода, который не является.

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

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

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

Ответ 5

Если вас также интересуют доказательства против юнит-тестирования, вот одна хорошо проработанная и продуманная статья:

Почему большая часть модульного тестирования является ненужной Джеймс О Коплиен (худой и ловкий гуру)

Ответ 6

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

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

Ответ 7

Здесь большое и интересное чтение парня, который меняет свою компанию изнутри. Он не ограничивается TDD. http://jamesshore.com/Change-Diary/ Обратите внимание, что он не убедил счетчики bean в течение некоторого времени и вместо этого использовал "партизанскую тактику".

Ответ 8

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

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

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

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

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

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

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

Ответ 9

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

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

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

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

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

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

Аннотация:

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

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