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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Start with something so simple that you don't notice that you do it. When training for a marathon, start by walking 9 meters and run 1 meter, repeat.

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

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

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

Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

All researchers seem to agree that TDD encourages better task focus and test coverage. The mere fact of more tests doesn't necessarily mean that software quality will be better, but the increased programmer attention to test design is nevertheless encouraging. If we view testing as sampling a very large population of potential behaviors, more tests mean a more thorough sample. To the extent that each test can find an important problem that none of the others can find, the tests are useful, especially if you can run them cheaply.

Table 1. A summary of selected empirical studies of test-driven development: industry participants*

Table 2. A summary of selected empirical studies of TDD: academic participants*

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

Абстрактный:

This paper provides a systematic meta-analysis of 27 studies that investigate the impact of Test-Driven Development (TDD) on external code quality and productivity.

The results indicate that, in general, TDD has a small positive effect on quality but little to no discernible effect on productivity. However, subgroup analysis has found both the quality improvement and the productivity drop to be much larger in industrial studies in comparison with academic studies. A larger drop of productivity was found in studies where the difference in test effort between the TDD and the control group's process was significant. A larger improvement in quality was also found in the academic studies when the difference in test effort is substantial; however, no conclusion could be derived regarding the industrial studies due to the lack of data.

Finally, the influence of developer experience and task size as moderator variables was investigated, and a statistically significant positive correlation was found between task size and the magnitude of the improvement in quality.