Значение инструментов покрытия тестового кода

Question

Мы начали использовать Part Cover для отслеживания покрытия тестовым кодом нашего приложения.IMO - это отличный инструмент для получения общего балла за ваши тесты и для выделения областей тестирования, где вы, возможно, немного ленились с тестами, но сегодня я написал тест и понял, что на самом деле он не тестировал ничего полезного, он просто увеличилсямое покрытие!

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

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

Answer 1

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

Answer 2

Я буду играть адвоката дьявола: если увеличение вашего покрытия означало написание теста, который «не проверял ничего полезного», то почему этот код был там? Для меня это было бы аргументом для удаления некоторого основного кода.

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

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

Я попал сюда более подробно: http://www.kdgregory.com/index.php?page=junit.coverage

Answer 3

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

если вы не используете чистый TDD, 100% в любом случае является довольно нереальной целью. Я обычно стараюсь использовать метод Роя Ошерова и проверяю вещи только с помощью логики (например, не прямые методы получения / установки или передачи). Но тогда чем выше, тем лучше, и может быть соблазнительно провести еще пару тестов, чтобы увеличить этот охват ..!

Answer 4

Хорошая рационализация;) Но мы ведь люди, и я, например, сплю намного лучше ночью, зная, что непроверенный метод или путь не превратили его в производство.