Если вы должны были указать минимальное процентное покрытие кода для модульных тестов, возможно, даже в качестве требования для фиксации в репозитории, что бы это было?
Пожалуйста, объясните, как вы пришли к вашему ответу (поскольку, если все, что вы сделали, это выбрать номер, то я мог бы сделать это сам;)
Эта проза Альберто Савойи отвечает именно на этот вопрос (красиво развлекательным образом!):
http://www.artima.com/forums/flat.jsp?forum=106&thread=204677
Testivus On Test Coverage
Раньше утром программист спросил великий мастер:"Я готов написать некоторые модульные тесты. Какое покрытие кода я должен ставить для?"
Великий мастер ответил:
"Не беспокойтесь о покрытии, просто напишите хорошие тесты".
Программист улыбнулся, поклонился и влево.
...
Позже в тот же день второй программист задал тот же вопрос.
Великий мастер указал на горшок кипящей воды и сказал:
"Сколько зерен риса нужно положить в этот горшок?"
Программист, выглядя озадаченным, ответил:
"Как я могу вам рассказать? Это зависит от того, сколько людей вам нужно кормить, как они голодны, что другое питание, которое вы обслуживаете, сколько риса у вас есть доступ и т.д."
"Именно", сказал великий мастер.
Второй программист улыбнулся, поклонился, и слева.
...
К концу дня третий программист пришел и попросил того же вопрос о покрытии кода.
"Восемьдесят процентов и не меньше!" Ответил хозяин суровым голосом, стучал кулаком по столу.
Третий программист улыбнулся, поклонился, и слева....
После этого последнего ответа молодой ученик подошел к великой мастер:
"Великий мастер, сегодня я подслушал вас, отвечая на тот же вопрос о охват кода тремя различными ответы. Почему?"
Великий мастер встал с стул:
"Принеси свежий чай со мной и расскажи об этом".
После того, как они наполнили свои чашки горячий зеленый чай, великолепный мастер начал отвечать:
"Первый программист является новым и просто начинает работу с тестированием. Сейчас у него много кода и нет тесты. Ему предстоит долгий путь; сосредоточив внимание на охвате кода в это время было бы удручающим и совершенно бесполезным. Хэс лучше просто привыкнуть к писать и запускать некоторые тесты. Он может беспокоиться о покрытии позже".
"Второй программист, с другой стороны, обладает большим опытом как при программировании и тестировании. Когда я ответил, спросив ее, сколько зерен риса, я должен положить в горшок, я помогла ей понять, что количество необходимое тестирование зависит от количества факторов, и она знает тех факторов лучше, чем я, - ее код в конце концов. Нет ни одного, простой, отвечающий, и shes достаточно умный обращаться с правдой и работать с что".
"Понятно, - сказал молодой ученик," но если нет простого простого ответ, тогда почему вы ответили третий программист "Восемьдесят процентов" не менее? "
Великий мастер смеялся так сильно и громко, что его живот свидетельствует о том, что он пили больше, чем просто зеленый чай, flopped вверх и вниз.
" Третий программист хочет только простых ответов - даже когда есть нет простых ответов... а потом нет следуйте за ними в любом случае. "
Молодой ученик и седой великий мастер закончил пить чай в созерцательной тишине.
Покрытие кода - это вводящая в заблуждение метрика, если целью является 100% охват (вместо 100% тестирования всех функций).
Так что доверяйте себе или вашим разработчикам тщательно и охватывайте каждый путь через свой код. Будьте прагматичны и не преследуйте магический 100% -ный охват. Если вы TDD ваш код, вы должны получить 90% + покрытие в качестве бонуса. Используйте код, чтобы выделить фрагменты кода, который вы пропустили (не должно происходить, если вы TDD, хотя.. поскольку вы пишете код только для прохождения теста. Никакой код не может существовать без его теста партнера.)
Покрытие кода велико, но функциональное покрытие еще лучше. Я не верю в то, что буду писать каждую строчку. Но я действительно верю в то, что вы написали 100% -ное покрытие всех функций, которые я хочу предоставить (даже для дополнительных крутых функций, которые я пришел с собой и которые не обсуждались во время встреч).
Мне все равно, будет ли у меня код, который не рассматривается в тестах, но мне все равно, будет ли я реорганизовывать свой код и в конечном итоге иметь другое поведение. Поэтому 100% -ная функциональность - моя единственная цель.
Мой любимый код покрытия на 100% со звездочкой. Звездочка появляется, потому что я предпочитаю использовать инструменты, которые позволяют мне отмечать определенные строки как строки, которые "не считаются". Если я покрыл 100% строк, которые "подсчитываются", я готов.
Основной процесс:
Таким образом, если я и мои сотрудники добавят новый код или изменят тесты в будущем, есть яркая строка, чтобы рассказать нам, если мы пропустили что-то важное - покрытие упало ниже 100%. Тем не менее, он также обеспечивает гибкость для решения различных приоритетов тестирования.
У меня был бы другой анекдот по охвату тестирования, который я хотел бы поделиться.
У нас есть огромный проект, в котором, через твиттер, я отметил, что с 700 модульными тестами, у нас есть только 20% охвата кода.
Скотт Гензельман ответил слова мудрости:
Правильно ли это 20%? Это 20% который представляет код ваших пользователей ударил больше всего? Вы можете добавить еще 50 тесты и добавьте только 2%.
Опять же, он возвращается к моему Testivus on Code Coverage Ответ. Сколько риса вы должны положить в горшок? Это зависит.
Принятый ответ дает хороший аргумент - нет ни одного номера, которое будет иметь смысл в качестве стандарта для каждого проекта. Есть проекты, которые просто не нуждаются в таком стандарте. В тех случаях, когда принятый ответ не подходит, на мой взгляд, описывается, как можно принять такое решение для данного проекта.
Я сделаю это. Я не являюсь экспертом в области тестирования и буду рад видеть более обоснованный ответ.
Во-первых, почему вы хотите навязать такой стандарт в первую очередь? В общем, когда вы хотите ввести эмпирическую уверенность в своем процессе. Что я подразумеваю под "эмпирической уверенностью"? Ну, настоящая цель правильность. Для большинства программ мы не можем знать это во всех входах, поэтому мы соглашаемся на то, что код хорошо протестирован. Это более узнаваемо, но по-прежнему является субъективным стандартом: всегда будет открыто обсуждать, встречались ли вы с ним или нет. Эти дебаты полезны и должны возникать, но они также вызывают неопределенность.
Покрытие кода - объективное измерение. Как только вы видите отчет о своем покрытии, нет никакой двусмысленности в отношении того, были ли выполнены стандарты. Верно ли это? Совсем нет, но он имеет четкое отношение к тому, насколько хорошо проверен код, который, в свою очередь, является нашим лучшим способом повысить уверенность в его правильности. Охват кода - это измеримое приближение неизмеримых качеств, о которых мы заботимся.
Некоторые конкретные случаи, когда эмпирический стандарт может добавить значение:
Покрытие кода не является одной метрикой; существует несколько различных способов измерения покрытия. Какой из них вы можете установить стандарт, зависит от того, что вы используете для этого стандарта.
Я использую две общие метрики в качестве примеров, когда вы можете использовать их для установки стандартов:
if), были ли эти ветки оценены? Это дает лучшее представление о логическом охватевашего кода: Сколько из возможных путей, которые может выполнить мой код, я тестировал?
Существует много других показателей (охват строк аналогичен охвату оператора, но дает разные числовые результаты для многострочных операторов, например: условный охват и охват маршрутов аналогичны охвату веток, но отражают более подробный обзор возможные перестановки выполнения программы, которые могут возникнуть.)
Наконец, вернемся к исходному вопросу: если вы установили стандарты покрытия кода, что это должно быть?
Надеюсь, в этот момент ясно, что мы говорим о приближении к началу, поэтому любое число, которое мы выбираем, будет по своей сути приблизительным.
Некоторые номера, которые можно выбрать:
Я не видел числа ниже 80% на практике и с трудом представляю случай, когда их можно было бы установить. Роль этих стандартов заключается в повышении уверенности в правильности, а цифры ниже 80% не особенно внушают уверенность. (Да, это субъективно, но опять же, идея состоит в том, чтобы сделать субъективный выбор один раз, когда вы устанавливаете стандарт, а затем используете объективное измерение в будущем.)
Вышеприведенное предполагает, что целью является правильность. Охват кода - это просто информация; это может иметь отношение к другим целям. Например, если вы обеспокоены ремонтопригодностью, вы, вероятно, заботитесь о свободной связи, которая может быть продемонстрирована с помощью тестируемости, которая, в свою очередь, может быть измерена (в определенных моделях) с помощью покрытия кода. Таким образом, ваш стандарт покрытия кода обеспечивает эмпирическую основу для приближения к качеству "ремонтопригодности".
85% было бы хорошим стартовым местом для критериев проверки.
Я бы выбрал множество более высоких баров для критериев доставки - в зависимости от критичности тестируемых подсистем/компонентов.
Если бы это был идеальный мир, 100% кода будет покрываться модульными тестами. Однако, поскольку это НЕ идеальный мир, это вопрос того, на что у вас есть время. В результате я рекомендую уделять меньше внимания конкретному проценту и уделять больше внимания критическим областям. Если ваш код хорошо написан (или, по крайней мере, его разумное факсимиле), должно быть несколько ключевых моментов, когда API-интерфейсы могут быть подвержены другому коду.
Сфокусируйте свои усилия по тестированию на этих API. Убедитесь, что API-интерфейсы 1) хорошо документированы и 2) имеют тестовые примеры, которые соответствуют документации. Если ожидаемые результаты не совпадают с документами, значит, у вас есть ошибка в вашем коде, документации или тестовых случаях. Все из них хороши для проверки.
Удачи!
Для хорошо спроектированной системы, где модульные тесты привели к разработке с самого начала, я бы сказал, что 85% - это довольно небольшое число. Малые классы, предназначенные для проверки, не должны быть трудными для покрытия лучше.
Легко снять этот вопрос с чего-то вроде:
Правда, но есть некоторые важные моменты в отношении покрытия кода. По моему опыту эта метрика на самом деле очень полезна, когда используется правильно. Сказав это, я не видел всех систем, и я уверен, что их много, где трудно увидеть анализ покрытия кода, добавив какую-либо реальную ценность. Код может выглядеть так по-разному, и объем доступной рамки тестирования может меняться.
Кроме того, мои рассуждения в основном касаются довольно коротких циклов обратной обратной связи. Для продукта, который я разрабатываю, кратчайший цикл обратной связи довольно гибкий, охватывающий все: от тестов класса до передачи сигналов между процессами. Тестирование поставляемого субпродукта обычно занимает 5 минут, и для такого короткого цикла обратной связи действительно можно использовать результаты тестирования (и, в частности, метрику покрытия кода, которую мы здесь просматриваем), чтобы отклонить или принять фиксации в репозитории.
При использовании показателя покрытия кода вы должны не просто иметь фиксированный (произвольный) процент, который должен быть выполнен.. Это не дает вам реальных преимуществ анализа покрытия кода, на мой взгляд. Вместо этого определите следующие показатели:
Новый код можно добавить, только если мы не перейдем к LWM, и мы не опускаемся ниже HWM. Другими словами, покрытие кода не разрешено уменьшать, а новый код должен быть покрыт. Обратите внимание, как я говорю, должен и не должен (объясняется ниже).
Но разве это не означает, что невозможно очистить старый проверенный мусор, который вам больше не нужен? Да, и почему вы должны прагматично относиться к этим вещам. Бывают ситуации, когда правила должны быть нарушены, но для вашей обычной повседневной интеграции я считаю, что эти показатели весьма полезны. Они дают следующие два значения.
Поддерживается тестируемый код. При добавлении нового кода вам действительно нужно приложить усилия, чтобы сделать код тестируемым, потому что вам придется попробовать и покрыть все это своими тестовыми примерами. Тестовый код обычно хорош.
Тестирование покрытия для устаревшего кода со временем увеличивается. Когда вы добавляете новый код и не можете его покрыть с помощью тестового примера, попробуйте вместо этого использовать старый код, чтобы обойти правило LWM. Это иногда необходимое обман, по крайней мере, дает положительный побочный эффект, что охват устаревшего кода будет увеличиваться с течением времени, делая на первый взгляд строгое соблюдение этих правил на практике прагматичным.
И снова, если цикл обратной связи слишком длинный, может быть совершенно непрактично настраивать что-то подобное в процессе интеграции.
Я также хотел бы упомянуть еще два общих преимущества метрики покрытия кода.
Анализ покрытия кода является частью анализа динамического кода (в отличие от статического, например, Lint). Проблемы, обнаруженные при анализе динамического кода (такими инструментами, как очищающее семейство, http://www-03.ibm.com/software/products/en/rational-purify-family) - это такие вещи, как неинициализированные чтения памяти (UMR), память утечки и т.д. Эти проблемы могут быть найдены только в том случае, если код покрывается выполненным тестовым примером. Код, который наиболее сложно охватить в тестовом примере, обычно является ненормальным случаем в системе, но если вы хотите, чтобы система терпела неудачу (например, трассировка ошибок вместо сбоя), вы можете приложить некоторые усилия для покрытия аномальных случаев в анализе динамического кода. С небольшим количеством неудач, UMR может привести к segfault или еще хуже.
Люди гордятся тем, что сохраняют 100% нового кода, и люди обсуждают проблемы тестирования с такой же страстью, как и другие проблемы с реализацией. Как эта функция может быть написана более подверженными проверке? Как вы собираетесь пытаться покрыть этот ненормальный случай и т.д.
И отрицательный, для полноты.
Вообще говоря, из нескольких документов, посвященных лучшим передовым технологиям, которые я прочитал, 80% для нового кода в модульных тестах - это точка, которая дает лучший доход. Если выше, то CC% дает меньшее количество дефектов для прилагаемого усилия. Это лучшая практика, которая используется многими крупными корпорациями.
К сожалению, большинство из этих результатов являются внутренними для компаний, поэтому нет публичных литератур, на которые я могу указать.
Я использую cobertura, и независимо от того, какой процент, я бы рекомендовал сохранить значения в задаче проверки cobertura в актуальном состоянии. Как минимум, продолжайте поднимать totallinerate и totalbranchrate чуть ниже текущего покрытия, но никогда не уменьшайте эти значения. Также привяжите к свойству свойства Ant build failure к этой задаче. Если сборка завершилась неудачей из-за отсутствия покрытия, вы знаете, что кто-то добавил код, но не протестировал его. Пример:
<cobertura-check linerate="0"
branchrate="0"
totallinerate="70"
totalbranchrate="90"
failureproperty="build.failed" />
Когда я думаю, что мой код недостаточно проверен, и я не уверен, что тестировать дальше, я использую покрытие, чтобы помочь мне решить, что тестировать дальше.
Если я увеличиваю покрытие в unit test - я знаю, что это unit test что-то стоит.
Это относится к коду, который не покрыт, покрыт 50% или покрыт 97%.
Покрытие кода - это еще одна метрика. Само по себе это может быть очень ошибочным (см. www.thoughtworks.com/insights/blog/are-test-coverage-metrics-overrated). Поэтому ваша цель не должна заключаться в том, чтобы обеспечить 100% -ный охват кода, а скорее для того, чтобы проверить все соответствующие сценарии вашего приложения.
Если вы проводили модульное тестирование на приличное время, я не вижу причин, чтобы он не приближался к 95%+. Однако, как минимум, я всегда работал с 80%, даже когда был новичком в тестировании.
Это число должно включать только код, написанный в проекте (исключая фреймворки, плагины и т.д.) и, возможно, даже исключать определенные классы, состоящие целиком из кода, написанного для вызовов внешнего кода. Этот тип звонка должен быть издеваемым/пропущенным.
Покрытие кода велико, но только до тех пор, пока выгоды, которые вы получаете от него, перевешивают затраты/усилия для его достижения.
Мы работаем над стандартом 80% в течение некоторого времени, однако мы просто заставили решение отказаться от этого и вместо этого сосредоточиться на нашем тестировании. Сосредоточившись на сложной бизнес-логике и т.д.,
Это решение было принято в связи с увеличением времени, которое мы потратили на покрытие охвата кода и поддержание существующих модульных тестов. Мы чувствовали, что дошли до того, что выгоды, которые мы получали от нашего покрытия кода, были считаны меньше, чем усилия, которые мы должны были выполнить для достижения этого.
Многие магазины не оценивают тесты, поэтому, если вы стоите выше нуля, по крайней мере, есть оценка стоимости - поэтому, возможно, ненулевой не плохой, поскольку многие из них все еще ноль.
В мире .Net люди часто цитируют 80% как разумные. Но они говорят это на уровне решения. Я предпочитаю измерять на уровне проекта: 30% может быть прекрасным для проекта пользовательского интерфейса, если у вас есть тесты Selenium и т.д., 20% для проекта уровня данных могут быть прекрасными, но 95% + может быть вполне достижимым для бизнеса слой правил, если не полностью необходим. Таким образом, общий охват может составлять, скажем, 60%, но критическая бизнес-логика может быть намного выше.
Я также слышал это: стремитесь к 100%, и вы нанесете 80%; но стремимся к 80%, и вы нажмете 40%.
Нижняя строка: примените правило 80:20, и пусть ваш счетчик ошибок в приложении поможет вам.
Проверьте Crap4j. Это немного более сложный подход, чем прямой охват кода. Он объединяет измерения покрытия кода со сложными измерениями, а затем показывает, какой сложный код в настоящее время не тестируется.
Мой ответ на эту загадку состоит в том, чтобы иметь 100% -ный охват кода, который вы можете проверить, и 0% -ный охват кода, который вы не можете проверить.
Моя текущая практика в Python заключается в том, чтобы разделить мои .py-модули на две папки: app1/и app2/и при выполнении модульных тестов рассчитать охват этих двух папок и визуально проверить (I должен автоматизировать это когда-нибудь), что app1 имеет 100% -ый охват, а app2 - 0%.
Когда/если я нахожу, что эти числа отличаются от стандартного исследования я и изменяют дизайн кода, чтобы покрытие соответствовало стандарту.
Это означает, что я могу рекомендовать достижение 100% -ного охвата библиотечного кода.
Я также иногда просматриваю app2/, чтобы проверить, могу ли я проверить любой код там, и если я могу переместить его в app1/
Теперь я не слишком беспокоюсь о совокупном охвате, потому что это может сильно варьироваться в зависимости от размера проекта, но, как правило, я видел от 70% до более 90%.
С python я должен был бы разработать smoke test, который мог бы автоматически запускать мое приложение во время измерения покрытия и, надеюсь, получить совокупность 100% при объединении smoke test с фиксированными цифрами.
Просмотр покрытия с другой точки зрения: хорошо написанный код с четким потоком управления является самым легким для покрытия, самым простым для чтения и, как правило, наименее ошибочным кодом. При написании кода с ясностью и укрываемостью, а также путем написания модульных тестов параллельно с кодом, вы получаете лучшие результаты IMHO.
На мой взгляд, ответ: "Это зависит от того, сколько у вас времени". Я пытаюсь достичь 100%, но я не делаю суеты, если я не получу его со временем.
Когда я пишу модульные тесты, я ношу другую шляпу по сравнению с шляпой, которую ношу при разработке кода производства. Я думаю о том, что утверждает тестируемый код и каковы ситуации, которые могут его нарушить.
Я обычно следую следующим критериям или правилам:
Что Unit Test должно быть формой документации о том, что ожидаемое поведение моих кодов, т.е. ожидаемый результат с определенным вводом и исключениями, которые он может бросить, что клиенты могут захотеть поймать (что должны знать пользователи моего кода?)
Чтобы Unit Test помог мне разобраться, какие условия, о которых я, возможно, еще не подумал. (Как сделать мой код стабильным и надежным?)
Если эти два правила не обеспечивают 100% -ный охват, пусть так и будет. Но однажды у меня есть время, я анализирую непокрытые блоки и строки и определяю, есть ли еще тестовые примеры без модульных тестов или если код необходимо реорганизовать для устранения ненужных кодов.
Это сильно зависит от вашего приложения. Например, некоторые приложения состоят в основном из GUI-кода, который не может быть проверен модулем.
Я не думаю, что может быть такое правило Ч/Б.
Код должен быть пересмотрен с особым вниманием к критическим деталям.
Однако, если он не был протестирован, у него есть ошибка!
В зависимости от критичности кода, где-нибудь от 75% -85% является хорошим правилом. Код доставки обязательно должен быть проверен более тщательно, чем в домашних утилях и т.д.
Это должно зависеть от того, на какой стадии жизненного цикла разработки приложений вы находитесь.
Если вы некоторое время находились в разработке и уже много реализовали код, и сейчас понимаете, что вам нужно подумать о покрытии кода, тогда вам нужно проверить свой текущий охват (если он существует), а затем использовать что базовый уровень для установления контрольных точек каждого спринта (или среднего повышения в течение периода спринтов), что означает принятие кодовой задолженности, продолжая доставлять конечное значение пользователя (по крайней мере, по моему опыту, конечный пользователь не заботится ни о каком бите, увеличение охвата тестированием, если они не видят новых функций).
В зависимости от вашего домена небезопасно снимать 95%, но я должен сказать, что в среднем вы будете смотреть на средний случай от 85% до 90%.
Я считаю, что лучшим признаком правильного охвата кода является то, что количество конкретных проблем, которые могут быть исправлены, разумно соответствует размеру кода единичных тестов, который вы создали.
Я думаю, что самое главное - знать, что такое тренд покрытия со временем, и понять причины изменений в тренде. Наблюдаете ли вы изменения в тренде, поскольку хорошие или плохие будут зависеть от вашего анализа причины.
Я предпочитаю делать BDD, который использует комбинацию автоматических приемочных испытаний, возможно, других интеграционных тестов и модульных тестов. Вопрос для меня в том, что целевой охват автоматизированного набора тестов в целом должен быть.
В стороне, ответ зависит от вашей методологии, языка, тестирования и инструментов покрытия. При выполнении TDD в Ruby или Python нетрудно поддерживать 100% покрытие, и это стоит того. Намного проще управлять 100% -ным охватом, чем покрытие на 90%. То есть гораздо легче заполнить пробелы в покрытии по мере их появления (и при выполнении пробелов в области TDD пробелы редки и обычно стоят времени), чем управлять списком пробелов в покрытии, которые вы не получили, и пропустить регрессии покрытия из-за вашего постоянного фона непокрытого кода.
Ответ также зависит от истории вашего проекта. Я только нашел, что это было практично в проектах, управляемых таким образом с самого начала. Я значительно улучшил охват крупных проектов, и это стоит того, но я никогда не считал целесообразным вернуться и заполнить каждый пробел в покрытии, потому что старый непроверенный код недостаточно хорошо понял, чтобы сделать это правильно и быстро.
Короткий ответ: 60-80%
Длинный ответ: Я думаю, что это полностью зависит от характера вашего проекта. Обычно я запускаю проект, проверяя каждую практическую часть. При первом "выпуске" проекта у вас должен быть довольно хороший базовый процент, основанный на типе программирования, которое вы делаете. В этот момент вы можете начать "обеспечивать соблюдение" минимального покрытия кода.
Мы ориентировались нa > 80% до нескольких дней назад, но после того, как мы использовали много сгенерированного кода, нам не нужен% age, а скорее сделайте рецензент для вызова требуемого покрытия.
Из публикации Testivus я считаю, что контекст ответа должен быть вторым программистом. Сказав это с практической точки зрения, нам нужны параметры/цели, к которым нужно стремиться. Я считаю, что это может быть "проверено" в Agile-процессе, анализируя код, который у нас есть архитектура, функциональность (истории пользователей), а затем придумать число. Основываясь на моем опыте в области "Телеком", я бы сказал, что 60% - хорошая оценка.