Покрытие кода в модульном тестировании - PullRequest
Новая
       13

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

4 голосов
/ 19 марта 2009

Это о библиотеках .NET (DLL).

Какие есть варианты для измерения кода, охватываемого тестовыми случаями? Стоит ли это усилий (измерение покрытия кода)? Интересно, что охватить 70% кода может быть слишком легко и почти невозможно выйти за пределы 90%.

[EDIT] Еще один интересный вопрос (поставленный "E Rolnicki"): Что считается разумным охватом%?

Ответы [ 6 ]

9 голосов
/ 19 марта 2009

NCover (как коммерческий, так и с открытым исходным кодом с тем же именем) и инструмент покрытия кода в Visual Studio в значительной степени являются вашими основными инструментами в мире MS.

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

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

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

3 голосов
/ 19 марта 2009

При рассмотрении охвата кода необходимо учитывать две вещи.

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

Возьмем, к примеру, этот фрагмент: 

if (a == 2)
{
    do_A_Stuff();
}

if (b == 3)
{
    do_B_Stuff();
}

Запустите тест, где a = 2, и второй тест, где b = 3. Это 100% охват кода. Но что происходит, когда с тестом, где а = 2 и б = 3? Это «Переменные отношения», которые могут привести к чрезмерной уверенности в показателях покрытия.

3 голосов
/ 19 марта 2009

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

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

3 голосов
/ 19 марта 2009

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

1 голос
/ 19 марта 2009

Visual Studio Team System Developer Edition включает покрытие кода. Это может быть включено при запуске модульных тестов.

Откройте .testrunconfig и выберите, для каких сборок вы хотите получить данные.

1 голос
/ 19 марта 2009

Я не использовал это лично, но один из моих коллег клянется nCover (http://www.ncover.com/).

Что касается покрытия, то, по крайней мере, в Ruby 70% легко, 90% выполнимо, а 100% редко возможно.

...