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

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

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

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

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

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

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

когда установить код требования к покрытию

во-первых, зачем вы хотите ввести такой стандарт в первую очередь? В общем, когда вы хотите ввести эмпирическую уверенность в свой процесс. Что я имею в виду под"эмпирической уверенностью"? Ну, настоящая цель достоверность. Для большинства программ мы не можем знать это на всех входах, поэтому мы соглашаемся на то, что код хорошо проверенный. Это более познаваемо, но все же является субъективным стандартом: он всегда будет открыт для спорьте, встречались вы с ним или нет. Эти прения полезны и должны проводиться, но они также обнажают неопределенность.

покрытия кода является объективным измерением: как только вы увидите свой отчет о покрытии, нет никакой двусмысленности о том, были ли выполнены стандарты полезны. Доказывает ли это правильность? Совсем нет, но он имеет четкое отношение к тому, насколько хорошо протестирован код, что, в свою очередь, является нашим лучшим способом повысить уверенность в его правильности. Покрытие кода измеримое приближение неизмеримых качеств, о которых мы заботимся.

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

• для удовлетворения заинтересованных сторон. для многих проектов есть различные субъекты, которые заинтересованы в качестве программного обеспечения, которые могут не участвовать в повседневной разработке программного обеспечения (менеджеры, технические руководители и т. д.) Говорить "мы собираемся написать все тесты, которые нам действительно нужны" неубедительно: они либо нужно полностью доверять, либо проверять с постоянным тщательным надзором (при условии, что у них даже есть техническое понимание для этого.) Обеспечение измеримых стандартов и объяснение того, как они разумно приближаются к фактическим целям, лучше.
• нормализовать поведение команды. заинтересованные стороны в сторону, если вы работаете в команде, где несколько человек пишут код и тесты, есть место для разночтений, что квалифицируется как "хорошо-проверено."У всех ваших коллег есть то же самое представление о том, какой уровень тестирования достаточно хорош? Скорее всего, нет. Как вы примиряете это? Найдите метрику, с которой вы все согласны, и примите ее как разумное приближение. Это особенно (но не исключительно) полезно в больших командах, где провода могут не иметь прямого контроля над младшими разработчиками, например. Сети доверия также имеют значение, но без объективных измерений групповое поведение легко становится непоследовательным, даже если все действуют хорошо вера.
• чтобы быть честным. даже если вы единственный разработчик и единственный участник вашего проекта, у вас могут быть определенные качества для программного обеспечения. Вместо того, чтобы делать постоянные субъективные оценки о том, насколько хорошо протестировано программное обеспечение (что требует работы), вы можете использовать покрытие кода в качестве разумного приближения, и пусть машины измеряют его для вас.

какие метрики использовать

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

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

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

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

какой процент требовать

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

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

некоторые числа, которые можно выбрать:

• 100%. Вы можете выбрать это, потому что вы хотите быть уверены, что все проверяется. Это не дает вам никакого представления о качестве теста, но говорит вам, что какой-то тест какого-то качества коснулся каждого утверждения (или ветви и т. д.) Опять же, это возвращается к степени уверенности: Если ваш охват ниже 100%, вы знаю некоторое подмножество вашего кода не проверено.
  • некоторые могут утверждать, что это глупо, и вы должны проверить только те части своего кода, которые действительно важны. Я утверждаю, что вы также должны поддерживать только те части кода, которые действительно важны. Покрытие кода может быть улучшено путем удаления непроверенного кода.
• 99% (или 95%, другие цифры в высоких девяностых.) Целесообразно в тех случаях, когда вы хотите передать уровень доверия как до 100%, но оставьте себе некоторый запас, чтобы не беспокоиться о случайном трудном для тестирования углу кода.
• 80%. Я видел эту цифру в несколько раз, и не совсем знаю, где это происходит. Я!--47-->думаю это может быть странное незаконное присвоение правила 80-20; как правило, намерение здесь состоит в том, чтобы показать, что большинство вашего кода проверяется. (Да, 51% также будет "большинство", но 80% больше отражает то, что большинство людей mean большинство.) Это подходит для средних случаев, когда "хорошо проверенный" не является высоким приоритетом (вы не хотите тратить усилия на тесты с низкой стоимостью), но достаточно приоритетным, что вы все равно хотели бы иметь какой-то стандарт на месте.

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

другие Примечания

вышеизложенное предполагает, что правильность является целью. Покрытие кода-это просто информация; это может иметь отношение к другим целям. Например, если вы обеспокоены ремонтопригодностью, вы, вероятно, заботитесь о свободной связи, что может быть продемонстрировано тестируемостью, которая, в свою очередь, может быть измерена (определенным образом) покрытием кода. Таким образом, ваш стандарт покрытия кода обеспечивает эмпирическую основу для аппроксимации качества "ремонтопригодности".

мой любимый охват кода-100% со звездочкой. Звездочка появляется, потому что я предпочитаю использовать инструменты, которые позволяют мне отмечать определенные строки как строки, которые "не считаются". Если я покрыл 100% строк, которые "подсчитывают", я закончил.

основной процесс:

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

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

Я бы еще anectode на покрытие тестами я хотел бы поделиться.

У нас есть огромный проект, в котором, через twitter, я отметил, что,С 700 модульных тестов, у нас есть только 20% покрытия кода.

Скотт Хансельман ответил мудрость:

это правильные 20%? Это 20% который представляет код ваших пользователей нажмите больше всего? Можно добавить еще 50 тесты и только добавить 2%.

опять же, он возвращается к моему Тестивус на покрытие кода ответ. Сколько риса положить в кастрюлю? Это зависит от.

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

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

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

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

удачи!

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

легко отклонить этот вопрос примерно так:

• покрытые строки не равны проверенной логике, и не следует слишком много читать в процентах.

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

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

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

• низкая отметка воды (LWM), самое низкое число непокрытых линий, когда-либо виденных в тестируемой системе
• высокая отметка воды (HWM), самый высокий процент охвата кода когда-либо видел для тестируемой системы

новый код может быть добавлен, только если мы не идем выше LWM, и мы не идем ниже HWM. Другими словами, покрытие кода не разрешено уменьшать, и новый код должен быть покрыт. Обратите внимание, как я говорю, должен и не должен (объяснено ниже).

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

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

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

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

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

• анализ покрытия кода является частью динамического анализа кода (в отличие от статического, т. е. Lint). Проблемы, обнаруженные во время динамического анализа кода (такими инструментами, как семейство purify,http://www-03.ibm.com/software/products/en/rational-purify-family) - это такие вещи, как неинициализированные чтения памяти (UMR), утечки памяти и т. д. эти проблемы могут быть найдены только в том случае, если код охвачен выполненным тестовым случаем. Код, который труднее всего охватить в тестовом случае, как правило, ненормальные случаи в системе, но если вы хотите, чтобы система изящно отказала (т. е. трассировка ошибок вместо сбоя), вы можете приложить некоторые усилия для покрытия ненормальных случаев в динамическом анализе кода. Если немного не повезет, UMR может привести к segfault или хуже.

• люди гордятся тем, что держат 100% для нового кода, и люди обсуждают проблемы тестирования с такой же страстью, как и другие проблемы с реализацией. Как эта функция может быть написана более проверяемым образом? Как бы вы попытались охватить этот ненормальный случай и т. д.

и отрицательный, для полноты.

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

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

в мире .Net люди часто цитируют 80% как reasonble. Но говорят об этом на уровне решения. Я предпочитаю измерять на уровне проекта: 30% может быть хорошо для проекта UI, если у вас есть селен и т. д. или ручные тесты, 20% для проекта уровня данных может быть хорошо, но 95%+ может быть вполне достижимым для бизнес-правил слой, если не полностью необходимо. Таким образом, общий охват может составлять, скажем, 60%, но критическая бизнес-логика может быть намного выше.

Я также слышал следующее: стремитесь к 100%, и вы достигнете 80%; но стремитесь к 80%, и вы достигнете 40%.

итог: примените правило 80: 20, и пусть количество ошибок вашего приложения поможет вам.

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

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

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

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

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

покрытие кода - это еще одна метрика. Само по себе это может вводить в заблуждение (см. www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated). Поэтому ваша цель должна заключаться не в достижении 100% покрытия кода, а в том, чтобы проверить все соответствующие сценарии вашего приложения.

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

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

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

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

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

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

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

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

мой ответ на этот вопрос, чтобы иметь 100% покрытия кода можно протестировать и 0% покрытия кода Вы не можете проверить.

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

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

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

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

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

с python, я должен быть в состоянии разработать тест дыма, который может автоматически запускать мое приложение при измерении покрытия и, надеюсь, получить аггреагат 100% при объединении теста дыма с unittest цифры.

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

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

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

Я обычно следую следующим критериям или правилам:

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

2. что модульный тест должен помочь мне обнаружить условия what if, о которых я, возможно, еще не думал. (Как сделать мой код стабильным и надежным?)

Если эти два правила не дают 100% покрытия, так и быть. Но как только у меня появляется время, я анализирую непокрытые блоки и строки и определяю, есть ли еще тестовые случаи без модульных тестов или код необходимо изменить, чтобы исключить ненужные коды.

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

Это в стороне, ответ зависит от вашей методологии, языка и инструментов тестирования и покрытия. При выполнении TDD в Ruby или Python нетрудно поддерживать 100% покрытие, и это стоит сделать. гораздо проще управлять 100% покрытием чем 90-то процентов покрытия. то есть, гораздо проще заполнить пробелы покрытия по мере их появления (и при выполнении TDD хорошо пробелы покрытия редки и обычно стоит вашего времени), чем управлять списком пробелов покрытия, которые вы не получили вокруг и пропустить регрессии покрытия из-за вашего постоянного фона непокрытого кода.

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

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

Я не думаю, что может быть такое правило B/W.
Следует пересмотреть кодекс с уделением особого внимания важнейшим деталям.
Однако, если он не был протестирован, у него есть ошибка!

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

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

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

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

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

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

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

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

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

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