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

StackOverflow https://stackoverflow.com/questions/90002

Вопрос

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

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

Это было полезно?

Решение

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

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

Testivus о тестировании

Рано утром программист спросил великого хозяина:

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

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

«Не беспокойтесь об охвате, просто напишите несколько хороших тестов».

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

...

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

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

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

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

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

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

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

...

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

«Восемьдесят процентов и не меньше!» Ответил Мастер строгим голосом, стуча его кулаком на столе.

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

...

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

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

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

«Пойдем, выпьем со мной свежего чая и поговорим об этом».

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

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

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

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

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

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

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В основе лежит следующий процесс:

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

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

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

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

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

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

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

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

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

Удачи!

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

Этот вопрос легко отклонить, сказав что-то вроде:

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

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

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

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

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

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

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

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

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

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

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

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

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

И минус, для полноты картины.

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

85% было бы хорошей отправной точкой для критериев проверки.

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

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

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

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

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

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

<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%, однако только что приняли решение отказаться от этого и вместо этого сосредоточиться на тестировании.Концентрация на сложной бизнес-логике и т. д.,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top