С ростом проекта определить, какой код протестирован, а какой нет, становится сложно, хотя подобная потребность возникает регулярно. Обычно это происходит тогда, когда в команде есть разные люди, и не все из них ответственно подходят к написанию тестов. В таком случае может страдать качество проекта.
Протестированность кода можно измерить. Для этого используют метрику "покрытие кода тестами" (code coverage). Покрытие анализируется тестовыми фреймворками, которые считают отношения строчек, задействованных в тестах, ко всем строчкам исходного кода. Например, если в коде есть условная конструкция, и она не проверяется тестами, это значит, что все строки кода, входящие в неё, не будут покрыты.
В Pytest покрытие меряется крайне просто. Достаточно установить одну зависимость и запустить тесты с правильным флагом:
poetry add pytest-cov
# В --cov передается имя пакета, по которому собирается статистика
poetry run pytest --cov=hexlet_pytest
# Примерный вывод
tests/test_example.py .. [ 66%]
tests/test_hexlet_pytest.py . [100%]
Name Stmts Miss Cover
-----------------------------------------------
hexlet_pytest/__init__.py 1 0 100%
hexlet_pytest/example.py 4 1 75%
-----------------------------------------------
TOTAL 5 1 80%
После выполнения всех тестов, Pytest выводит сводную таблицу по каждому файлу. В ней показан процент покрытия кода тестами. В примере выше видно что в файле init.py покрыто 100% кода, а вот в файле example.py только 75%. При этом общее покрытие кода 80%. Обратите внимание, что покрытие сильно зависит от того, какие тесты выполнились. Если часть из них упала с ошибками, то Pytest покажет намного меньшее покрытие, так как тесты просто не доберутся до всего кода. Поэтому покрытие меряют только тогда, когда все тесты зелёные.
Эта статистика помогает найти места, где тестов мало. Дальше по ситуации их можно начинать добавлять. Если в проекте тестов не было вообще, то эта статистика начинает быстро расти. А вот дальше, ближе к 90 процентам, придётся бороться за каждую строчку кода.
Однако покрытие само по себе не гарантирует, что покрытый код работает правильно во всех ситуациях. Логические ошибки в коде невозможно отследить только покрытием. Для этого нужны тесты на одну и ту же функциональность, но с разным набором данных. Как правило, это тесты на пограничные случаи. В разработке есть хорошая практика: перед тем как чинить баги, сначала нужно написать тесты, которые их воспроизводят, и только затем уже можно починить их.
Какое покрытие считается допустимым? 100% покрытия выглядит красиво, но добиться его невероятно сложно. И для большинства проектов бессмысленно. Затраченные усилия не окупятся. Большинство разработчиков сходится во мнении, что 80% — это достаточно хорошее покрытие. На этом можно и остановиться.
--cov=hexlet_python_package
при запуске тестов, посмотрите как изменился выводВам ответят команда поддержки Хекслета или другие студенты.
Выделите текст, нажмите ctrl + enter и отправьте его нам. В течение нескольких дней мы исправим ошибку или улучшим формулировку.
Загляните в раздел «Обсуждение»:
Статья «Ловушки обучения»
Вебинар «Как самостоятельно учиться»
Базовый план откроет полный доступ ко всем курсам, упражнениям и урокам Хекслета, проектам и пожизненный доступ к теории пройденных уроков. Подписку можно отменить в любой момент.
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Наши выпускники работают в компаниях:
С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.
Зарегистрируйтесь или войдите в свой аккаунт