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

[lair]

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

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

[lavice]

Спасибо.

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

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

[lair]

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

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

[lavice]

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

[lair]

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

[lavice]

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

[alt-j]

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

[lair]

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

[alt-j]

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

[lair]

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

[lavice]

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

[EngineerSpock]

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

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

[lair]

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

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

[EngineerSpock]

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