Как вы рассчитываете процент покрытия кода автотестами?

общие вопросы
#1

Как вы рассчитываете процент покрытия кода автотестами?

Проверить сode coverage
#2

О каких тестах идёт речь? О функциональных? Почему метрика “покрытие кода” определена как важная?

#3 
О каких тестах идёт речь? О функциональных?

О функциональных ГУИшных автотестах.

Почему метрика "покрытие кода" определена как важная?

Да какая разница почему!? Вопрос данной темы “Как”, а не “Почему”.

#4

Вопрос топика звучит

То есть ты считаешь, что эту метрику собирают

Если метрика не важна, то её и не меряют. Никак.

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

P.S. В другой раз за такие возмущения тему буду скрывать пока не сформулируешь нормально вопрос. Прочитай FAQ на досуге

1 лайк
#5 
P.S. В другой раз за такие возмущения тему буду скрывать пока не сформулируешь нормально вопрос. Прочитай FAQ на досуге

Ок, закрывай тему.

#6

Используйте code coverage tools. Какой именно из них использовать, зависит от того, на каком языке программирования написано тестируемое приложение. Например, для Java - Cobertura, JaCoCo, Clover, .NET - dotCover + есть еще поставляемый с Visual Studio набор performance tools. Самое главное, эти все средства оценки покрытия, как правило, имеют 2 основные стадии:

  • instrumentation - получение информации о всех классах, по которым нужно оценивать покрытие и установка прослушки
  • finalization - сбор данных по покрытию и формаирование единого отчета.
    Так что если вы хотите измерить покрытие кода, то вам нужно запустить тесты между этими стадиями. Если вы используете движки типа xUnit, то в ряде случаев запуск таких тестов в оценкой покрытия обеспечивается движками сборки (например, в Maven это так и делается). В остальных случаях все можно свести к запускам командной строки. Более конкретно можно эту тему осветить при наличии деталей касательно используемых технологий
2 лайка
#7

В зависимости от типа тестов.

  1. Для юнит-тестов на Java мы рассчитываем покрытие прямо в Intellij IDEA - там есть встроенная кнопка. Или с помощью распространённой библиотеки JaCoCo. Для юнит-тестов JavaScript подойдёт Karma, она умеет считать покрытие.
  2. Для UI-тестов рассчитывать покрытие особо не имеет смысла, потому что при запуске UI-тестов помимо строк кода на Java, задействовано много других составляющих: JavaScript, CSS, Less, база данных и пр. На сегодняшний день, наверное, не существует технологии, позволяющий посчитать покрытие для всех этих созданий.
2 лайка
#8

Немного странный вопрос ИМХО.
Code Coverage - адекватен для модульных тестов. Для функциональных тестов, где тестируется через чёрный ящик - данная метрика не будет иметь смысла, ибо при составлении тестов учитываются не ветвления кода (мы о них не имеем ни малейшего представления), а покрытие требований. В таком случае необходима traceability matrix, а не code coverage.
Где-то так…

1 лайк
#9

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

Далее, некоторые участки кода можно полноценно проверить только в случае запуска компонента или системы в целом (как правило, это обработчики событий). Просто может выйти дешевле протестировать их на уровне системных тестов.

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

И наконец, ни одна метрика оценки покрытия (кода или требований) не дает полной картины реального покрытия. У всех есть недостатки. Чтобы с более-менее высокой уверенностью сказать, что тот или иной модуль протестирован на N%, нужно комбинировать метрики. И покрытие кода просто добавляет свою часть в общую картину