Каков разумный охват кода% для модульных тестов (и почему)? [закрыто]

Мы были нацелены> 80% до нескольких дней назад, Но после того, как мы использовали много Сгенерированного кода, Мы не заботимся о %age, а скорее заставляем рецензента взять запрос к требуемому покрытию.

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

В зависимости от критичности кода, где угодно от 75%-85% хорошее эмпирическое правило. Поставка кода должна определенно быть протестирована более тщательно, чем в утилитах дома, и т.д.

Короткий ответ: 60-80%

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

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

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

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

у Нас есть огромный проект, где по Твиттеру я отметил, что, с 700 модульными тестами, у нас только есть 20%-е покрытие кода .

Scott Hanselman ответил с слова мудрости :

действительно ли это - ПРАВИЛЬНЫЕ 20%? Действительно ли это - 20%, который представляет код, который Ваши пользователи поражают больше всего? Вы могли бы добавить еще 50 тестов и только добавить 2%.

Снова, это возвращается к моему Testivus на Покрытии Кода Ответ. Сколько риса необходимо вставить горшок? Это зависит.

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

Если бы это было идеальным миром, 100% кода были бы покрыты модульными тестами. Однако, так как это не идеальный мир, это - вопрос того, для чего у Вас есть время. В результате я рекомендую фокусироваться меньше на определенном проценте и сфокусироваться больше на критических областях. Если Ваш код правильно написан (или по крайней мере разумное факсимиле этого) должно быть несколько ключевых пунктов, где API представлены другому коду.

Фокус Ваши усилия по тестированию на этих API. Удостоверьтесь, что API 1) хорошо документируются и 2) записали тестовые сценарии, которые соответствуют документации. Если ожидаемые результаты не совпадают с документами, то у Вас есть ошибка или в Вашем коде, документации или в тестовых сценариях. Все из которых хороши для проверки.

Удачи!

Это должно зависеть от того, в какой фазе Вашего жизненного цикла разработки приложений Вы находитесь.

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

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

Мой ответ на эту загадку должен иметь 100%-е покрытие строки кода, который можно протестировать и 0%-е покрытие строки кода, который Вы не можете протестировать.

Моя существующая практика в Python должна разделить мои .py модули на две папки: app1/и app2/и когда рабочие модульные тесты вычисляют покрытие тех двух папок и визуально проверяют (я должны автоматизировать это когда-нибудь), что app1 имеет 100%-е покрытие, и app2 имеет 0%-е покрытие.

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

Это действительно означает, что я могу рекомендовать достигнуть 100%-го покрытия строки кода библиотеки.

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

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

С Python, я должен быть в состоянии создать испытание с помощью дыма, которое могло автоматически запустить мое приложение при измерении покрытия и надо надеяться получить aggreagate 100% при объединении испытания с помощью дыма с числами unittest.

Покрытие кода является большим, но только, пока польза, которую Вы извлекаете из него, перевешивает стоимость/усилие достижения его.

Мы работали к стандарту 80% в течение некоторого времени, однако мы только что сделали decison, чтобы отказаться от этого и вместо этого быть более сфокусированными на нашем тестировании. При концентрации на сложной бизнес-логике и т.д.,

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

85% были бы хорошим стартовым местом для критериев регистрации.

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

Если Вы делали поблочное тестирование на достойное количество времени, я не вижу оснований для него для не приближения к 95% +. Однако как минимум я всегда работал с 80%, даже когда новый для тестирования.

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

Покрытие кода является вводящей в заблуждение метрикой, если 100%-е покрытие является Вашей целью (вместо тестирования 100% всех функций).

• Вы могли получить 100% путем удара всех строк однажды. Однако Вы могли все еще пропустить тестирование конкретной последовательности (логический путь), в котором поражены те строки.
• Вы не могли получить 100%, но все еще протестировали используемые пути выполнения кода всех Ваших 80%/freq. Наличие тестов, которые тестируют каждый 'бросок ExceptionTypeX' или подобная защита безопасного программирования, которую Вы вставили, 'хорошо иметь' не, 'должен иметь'

, Так доверяйте себе или Вашим разработчикам, чтобы быть полными и покрыть каждый путь через их код. Будьте прагматически настроены и не преследуйте волшебное 100%-е покрытие. Если Вы TDD Ваш код необходимо получить 90% + покрытие в качестве награды. Используйте покрытие кода для выделения блоков кода, который Вы пропустили (не должен происходить если Вы TDD хотя.. так как Вы пишете код только для создания тестовой передачи. Никакой код не может существовать без своего теста партнера.)

Вообще говоря, из нескольких технических газет лучших практик превосходства, которые я прочитал, 80% для нового кода в модульных тестах являются точкой, которая приводит к лучшему возврату. Выход за предел того % CC приводит к более низкой сумме дефектов для проявленного усилия. Это - лучшая практика, которая используется многими крупнейшими корпорациями.

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

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

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

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

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />

Охват кода большой, но функциональность еще лучше. Я не верю в освещение каждой отдельной строки, которую я пишу. Но я верю в то, что напишу на 100% тестовое покрытие всей функциональности, которую я хочу предоставить (даже для очень крутых функций, которые я пришел с собой и которые не обсуждались во время встреч).

Мне все равно, буду ли я иметь код, который не описан в тестах, но мне было бы интересно, если бы я реорганизовал свой код и в конечном итоге имел другое поведение. Поэтому 100% функциональность - моя единственная цель.

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

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

Это касается кода, который не покрыт, покрыт на 50% или покрыт на 97%.