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

Question

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

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

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

Answer 1

По моему опыту модульное тестирование помогло мне со следующими вещами:

• Теперь я могу сосредоточиться на блоке кода / функции / классе, который я пишу, не беспокоясь ни о чем другом, потому что я знаю, если я сделаю что-нибудь глупое или вызову побочный эффект, мои тесты скажут мне
• Я могу реорганизовать вещи, зная, что я не ломаю вещи
• Я уверен, что мое приложение работает как положено
• Перед выпуском я не проверяю все функции вручную, чтобы убедиться, что приложение все еще работает,
• Я уверен, что мое приложение всегда стабильно на каком-то уровне

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

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

P.S. Исходя из вашего уровня ошибок и того, что вы сказали, вы все равно звучите как гений (при условии, что это средние или большие проекты), поэтому я бы сказал, что не используйте юнит-тесты, похоже, у вас все хорошо. Но для остального мира, не такого гениального, как я, я настоятельно рекомендую Unit Test, потому что он работал для меня.

Answer 2

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

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

Answer 3

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

Формальное модульное тестирование требует значительных усилий и усилий для обслуживания. Я предполагаю, что на разработку программного обеспечения уходит 20-50% времени. То, что я спрашиваю, - это известная цена добавления 20-50% накладных расходов на каждое усилие по разработке, это выигрыш, заслуживающий внимания и / или доказуемый.

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

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

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

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

Answer 4

Я получил большую пользу, используя Test Driven Development (TDD) с C ++ в огромном монолитном серверном приложении.

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

В этом случае у меня огромный прирост производительности.

• Чтобы построить и запустить мой тест: 10 секунд.
• Чтобы собрать, запустить и вручную протестировать полный сервер: минимум 5 минут.

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

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

Answer 5

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

Answer 6

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

Все остальное просто магия;)