lavice Dec 25 2012 at 12:16

Автоматический анализ покрытия кода с использованием OpenCover + плюшки

3 min

11K

Comments 14

lair Dec 25 2012 at 12:40

Два занятных пункта.

Во-первых, Code coverage есть в студии, и тоже неплохо интегрируется в билд (а особенно в TFS Build).
Во-вторых, опыт показал, что покрытие строчки кода совершенно не означает, что покрывающий ее тест что-то проверяет. То есть представьте, что в вашем примере с подсветкой кода есть еще переменная j=0, и внутри if используется она. Покрытие не будет меняться вне зависимости от того, проверяет тест, какая переменная используется, или нет.

lavice Dec 25 2012 at 13:04

Спасибо.

1 — я знаком с code coverage, но особенности нашего CI таковы, что нам неудобно его использовать. Да и не особо он понравился, если честно. OpenCover + ReportGenerator — удобно и информативно, а также универсально.

2 — да, полностью с вами согласен. Но мы говорим об анализе именно покрытия тестами, а не их качества

lair Dec 25 2012 at 13:07

А смысл анализировать покрытие кода, если вы не знаете, насколько в реальности это покрытие полезно?

Я как раз предостерегаю от этой ловушки — думать, что если в проекте 100% покрытие тестами, то там все хорошо. И, соответственно, от (бездумного) использования метрик на code coverage в билде, потому что как раз они приводят к написанию тестов, которые формально код покрывают, а по факту ничего не делают. Это личный только что пережитый опыт.

lavice Dec 25 2012 at 13:16

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

lair Dec 25 2012 at 13:18

В общем, я бы рекомендовал делать метрику не на некую величину уровня покрытия, а на неуменьшение этой величины. Это позитивнее.

lavice Dec 25 2012 at 13:31

По сути, у мы так и делаем. Есть минимально допустимый уровень покрытия, например 70%, и эта цифра не должна уменьшаться. В свою очередь, увеличение не является обязательным, но приветствуется :)

alt-j Dec 25 2012 at 23:24

Тот же ReSharper + dotCover позволяет проанализировать покрытие кода, куда лучше ИМХО

lair Dec 26 2012 at 06:44

(1) решарпер для этого не нужен, нужен только dotCover
(2) dotCover, все-таки, платный

alt-j Dec 26 2012 at 10:13

(1) собственно именно для измерения покрытия — нет, но сам процесс тестирования и рефакторинга эта связка делает значительно более приятным.
(2) да, но смотря для каких проектов использовать, иногда проще заплатить

lair Dec 26 2012 at 10:19

Теперь попробуйте прикрутить эту связку на билд-сервер. Раз уж она делает процесс тестирования более приятным.

lavice Dec 26 2012 at 10:27

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

EngineerSpock Dec 30 2012 at 16:11

Боб Мартин рекомендует стремиться к 100% покрытию, хотя сам и говорит, что эта цифра нереальна. Такую рекомендацию он даёт в Clean Code Episode, посвящённому TDD.

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

lair Dec 30 2012 at 21:50

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

Как уже было сказано выше, покрытие «по исполнению» показывает те места, где тестов точно нет. А вот если строчка исполнена — то еще не факт, что она протестирована.

EngineerSpock Dec 31 2012 at 05:45

Да, совершенно верно. Я не уточнил. Это одна из причин почему 100% покрытие не гарантирует того, что в рантайме не будет багов.