Обеспечение покрытия кода при модульном тестировании?

Я заметил, что, несмотря на то, что у меня много доктестов в нашем коде на Python, когда я отслеживаю тестирование с помощью методов, описанных здесь:

traceit

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


python unit-testing testing code-coverage
person reckoner    schedule 23.07.2010    source источник

Ответы (2)


arrow_upward
30
arrow_downward

coverage.py — очень удобный инструмент. Помимо прочего, он обеспечивает покрытие филиалов.

person Hank Gay    schedule 23.07.2010
comment
Этот ответ был бы более полезным, если бы вы предоставили краткий пример того, как использовать coverage.py. - person SimplyKnownAsG; 10.04.2015
comment
@SimplyKnownAsG Связанная страница имеет раздел «Быстрый старт» спереди и по центру и включает пример использования. Вместо того, чтобы копировать и вставлять документацию, которая может меняться по мере выхода новых версий, я считаю, что лучше просто давать ссылки. - person Hank Gay; 10.04.2015
comment
Как использовать coverage.py: github.com/audreyr/how-to /блоб/мастер/питон/ - person Dušan Maďar; 14.03.2017

arrow_upward
19
arrow_downward

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

Хотя покрытие кода — это здорово, потому что вы, конечно, не можете сказать, что часть кода протестирована, пока к ней не прикоснулись, я просто не приравниваю касание части кода к тому, чтобы назвать ее протестированной. Я не против покрытия кода, но слишком легко использовать покрытие кода в качестве метрики, чтобы знать, когда тестирование завершено. Я думаю, это было бы ошибкой.

person Brad Barker    schedule 23.07.2010
comment
Это отличный комментарий. В моей ситуации код Python пишут ученые, а не программисты. В результате, несмотря на то, что ученые очень умны, код разработан очень плохо. Это означает, что окончательная интеграция и тестирование — это кошмар, и нам приходится слишком много работать, чтобы выявить серьезные проблемы на этом этапе. Я пытаюсь заставить их написать лучшие тестовые примеры для кода, за который каждый из них отвечает, и я планирую использовать покрытие кода как способ квалификации тестирования, которое они интегрируют. Я понимаю, что не 100% кода нужно трогать, но это помогло бы. - person reckoner; 24.07.2010
comment
Наличие 100% покрытия не является гарантией достаточности тестов, но его отсутствие обычно указывает на отсутствие достаточного количества тестов. Не будем также забывать, что модуль покрытия позволяет использовать такие комментарии, как # pragma: no cover и # pragma: no branch. - person Acumenus; 30.03.2017