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

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

Пожалуйста, объясните, как вы пришли к вашему ответу (поскольку, если все, что вы сделали, это выбрать номер, то я мог бы сделать это сам;)

+435
источник поделиться
30 ответов

Эта проза Альберто Савойи отвечает именно на этот вопрос (красиво развлекательным образом!):

http://www.artima.com/forums/flat.jsp?forum=106&thread=204677

Testivus On Test Coverage

Раньше утром программист спросил великий мастер:

"Я готов написать некоторые модульные тесты. Какое покрытие кода я должен ставить для?"

Великий мастер ответил:

"Не беспокойтесь о покрытии, просто напишите хорошие тесты".

Программист улыбнулся, поклонился и влево.

...

Позже в тот же день второй программист задал тот же вопрос.

Великий мастер указал на горшок кипящей воды и сказал:

"Сколько зерен риса нужно положить в этот горшок?"

Программист, выглядя озадаченным, ответил:

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

"Именно", сказал великий мастер.

Второй программист улыбнулся, поклонился, и слева.

...

К концу дня третий программист пришел и попросил того же вопрос о покрытии кода.

"Восемьдесят процентов и не меньше!" Ответил хозяин суровым голосом, стучал кулаком по столу.

Третий программист улыбнулся, поклонился, и слева.

...

После этого последнего ответа молодой ученик подошел к великой мастер:

"Великий мастер, сегодня я подслушал вас, отвечая на тот же вопрос о охват кода тремя различными ответы. Почему?"

Великий мастер встал с стул:

"Принеси свежий чай со мной и расскажи об этом".

После того, как они наполнили свои чашки горячий зеленый чай, великолепный мастер начал отвечать:

"Первый программист является новым и просто начинает работу с тестированием. Сейчас у него много кода и нет тесты. Ему предстоит долгий путь; сосредоточив внимание на охвате кода в это время было бы удручающим и совершенно бесполезным. Хэс лучше просто привыкнуть к писать и запускать некоторые тесты. Он может беспокоиться о покрытии позже".

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

"Понятно, - сказал молодой ученик," но если нет простого простого ответ, тогда почему вы ответили третий программист "Восемьдесят процентов" не менее? "

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

" Третий программист хочет только простых ответов - даже когда есть нет простых ответов... а потом нет следуйте за ними в любом случае. "

Молодой ученик и седой великий мастер закончил пить чай в созерцательной тишине.

+981
источник

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

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

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

+67
источник

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

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

+36
источник

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

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

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

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

+17
источник

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

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

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

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

Опять же, он возвращается к моему Testivus on Code Coverage Ответ. Сколько риса вы должны положить в горшок? Это зависит.

+16
источник

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

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

Когда для установки требований покрытия кода

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

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

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

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

Какие показатели для использования

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

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

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

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

Какой процент требуется

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

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

Некоторые номера, которые можно выбрать:

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

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

Другие примечания

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

+16
источник

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

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

+7
источник

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

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

Удачи!

+7
источник

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

Легко снять этот вопрос с чего-то вроде:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+4
источник

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

<cobertura-check linerate="0"
                 branchrate="0"
                 totallinerate="70"
                 totalbranchrate="90"
                 failureproperty="build.failed" />
+4
источник

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

Если я увеличиваю покрытие в unit test - я знаю, что это unit test что-то стоит.

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

+4
источник

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

+4
источник

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

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

+3
источник

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

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

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

+3
источник

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

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

Я также слышал это: стремитесь к 100%, и вы нанесете 80%; но стремимся к 80%, и вы нажмете 40%.

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

+3
источник

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

+2
источник

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

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

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

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

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

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

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

+2
источник

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

+2
источник

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

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

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

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

  • Чтобы Unit Test помог мне разобраться, какие условия, о которых я, возможно, еще не подумал. (Как сделать мой код стабильным и надежным?)

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

+2
источник

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

+1
источник

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

+1
источник

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

+1
источник

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

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

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

+1
источник

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

+1
источник

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

+1
источник

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

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

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

+1
источник

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

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

0
источник

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

0
источник

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

0
источник

Посмотрите другие вопросы по меткам или Задайте вопрос