У кого-нибудь есть метрики на полезность формального юнит-тестирования?

Question

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

Я прекратил формальное модульное тестирование более 5 или 6 лет назад, и чистый прирост производительности кажется довольно высоким. Я прекратил модульное тестирование, потому что заметил, что оно никогда ничего не ловит, не говоря уже о чем-то полезном. Тип ошибок, которые обнаруживает модульное тестирование, можно предотвратить, если выпить не более 2 стаканов вина / пива в час (или 2 стакана в час). Кроме того, модульное тестирование, по-видимому, создает риск, позволяя разработчику думать, что есть какая-то мера предосторожности, чтобы поймать их ошибки.

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

Answer 1

Я признаю ваше превосходство как человека и программиста.

Я, однако, простой придурок, и без юнит-теста Python я был бы потерян.

Я не могу провести рефакторинг без юнит-тестов, просто слишком много думать.

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

Я юнит-тест, потому что я идиот. Поскольку вы не делаете ошибок, вам явно не нужно юнит-тестирование. Я приветствую вас.

---

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

Answer 2

Вот небольшая статья о модульном тесте, которая может вам помочь:

• Белая бумага # 1
• Белая бумага # 2
• Белая бумага # 3

Но, Мартин Фаулер выразился, неподтвержденная информация в поддержку модульных тестов и TDD огромна, но вы не можете измерить производительность.

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

Answer 3

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

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

Вероятно, несколько других, о которых я забыл: -P

PS: Откуда вы знаете, что не делаете ошибок? Я не думаю, что я привносил ошибки в код, над которым я работаю, но это определенно не делает его таким. ИМХО, наивно думать, что в вашем коде нет ошибок.

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

Answer 4

Вот поток, который имеет некоторое исследование о подходе TDD Исследования по TDD

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

Answer 5

У меня нет метрик, на которые можно было бы указать, но я думаю, что рост популярности объясняется тем, что у всех нас был опыт, противоположный вашему. :)

Answer 6

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

Заметного изменения частоты ошибок не произошло, но, возможно, пока рано говорить.

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

Answer 7

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

Вот интересное обсуждение утилиты модульных тестов.

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

Answer 8

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

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

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

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

Answer 9

Мне кажется, что формальное модульное тестирование с использованием популярных инструментов тестирования во многом похоже на безопасность в аэропортах США.

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

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

Полагаю, поклонники формального юнит-тестирования будут по-прежнему чувствовать себя в безопасности. Я буду продолжать писать свою спецификацию на клочке бумаги и положить в миску у ног моей статуи Святого Антония и помолиться. Кто скажет, какой путь более эффективен, но мой путь, конечно, приятен ... Может быть, я напишу об этом.

Answer 10

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