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

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

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

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

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

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

Зачем?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Аннотация:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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