0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>С ростом проекта, определить какой код протестирован, а какой нет, становится сложно, хотя подобная потребность возникает регулярно. Обычно это происходит тогда, когда в команде есть разные люди и не все из них ответственно подходят к написанию тестов. В таком случае может страдать качество проекта.</p>
1
<p>С ростом проекта, определить какой код протестирован, а какой нет, становится сложно, хотя подобная потребность возникает регулярно. Обычно это происходит тогда, когда в команде есть разные люди и не все из них ответственно подходят к написанию тестов. В таком случае может страдать качество проекта.</p>
2
<p>Протестированность кода можно измерить. Для этого используют метрику "покрытие кода тестами" (code coverage). Покрытие анализируется тестовыми фреймворками, которые считают отношения строчек, задействованных в тестах, ко всем строчкам исходного кода. Например, если в коде есть условная конструкция, и она не проверяется тестами, это значит, что все строки кода, входящие в неё, не будут покрыты.</p>
2
<p>Протестированность кода можно измерить. Для этого используют метрику "покрытие кода тестами" (code coverage). Покрытие анализируется тестовыми фреймворками, которые считают отношения строчек, задействованных в тестах, ко всем строчкам исходного кода. Например, если в коде есть условная конструкция, и она не проверяется тестами, это значит, что все строки кода, входящие в неё, не будут покрыты.</p>
3
<p>В JUnit, к сожалению, нет встроенного метода, который измеряет покрытие кода тестами. Однако, есть дополнительные утилиты с помощью которых вы сможете получить эти данные. Например, если вы используете Gradle, то можно подключить<a>JaCoCo-плагин</a>. Пример подключения можно подсмотреть в<a>этом</a>репозитории.</p>
3
<p>В JUnit, к сожалению, нет встроенного метода, который измеряет покрытие кода тестами. Однако, есть дополнительные утилиты с помощью которых вы сможете получить эти данные. Например, если вы используете Gradle, то можно подключить<a>JaCoCo-плагин</a>. Пример подключения можно подсмотреть в<a>этом</a>репозитории.</p>
4
<p>После выполнения всех тестов, в директории<em>target/site/jacoco</em>будет располагаться сформированный отчёт. Для того, чтобы ознакомиться с ним достаточно открыть в браузере<em>index.html</em>. В отчёте находится интерактивная таблица, которая по умолчанию показывает общий процент покрытия кода тестами. Вы можете также отдельно увидеть покрытие каждого пакета или даже класса.<strong>Отчёт будет сформирован только в том случае если тесты пройдут успешно.</strong></p>
4
<p>После выполнения всех тестов, в директории<em>target/site/jacoco</em>будет располагаться сформированный отчёт. Для того, чтобы ознакомиться с ним достаточно открыть в браузере<em>index.html</em>. В отчёте находится интерактивная таблица, которая по умолчанию показывает общий процент покрытия кода тестами. Вы можете также отдельно увидеть покрытие каждого пакета или даже класса.<strong>Отчёт будет сформирован только в том случае если тесты пройдут успешно.</strong></p>
5
<p>Эта статистика помогает найти места, где тестов мало. Дальше по ситуации их можно начинать добавлять. Если в проекте тестов не было вообще, то эта статистика начинает быстро расти. А вот дальше, ближе к 90 процентам, придётся бороться за каждую строчку кода.</p>
5
<p>Эта статистика помогает найти места, где тестов мало. Дальше по ситуации их можно начинать добавлять. Если в проекте тестов не было вообще, то эта статистика начинает быстро расти. А вот дальше, ближе к 90 процентам, придётся бороться за каждую строчку кода.</p>
6
<p>Однако, покрытие само по себе не гарантирует, что покрытый код работает правильно во всех ситуациях. Логические ошибки в коде невозможно отследить только покрытием. Для этого нужны тесты на одну и ту же функциональность, но с разным набором данных. Как правило это тесты на пограничные случаи. В разработке есть хорошая практика: перед тем как чинить баги, сначала нужно написать тесты, которые их воспроизводят, и только затем уже можно починить их.</p>
6
<p>Однако, покрытие само по себе не гарантирует, что покрытый код работает правильно во всех ситуациях. Логические ошибки в коде невозможно отследить только покрытием. Для этого нужны тесты на одну и ту же функциональность, но с разным набором данных. Как правило это тесты на пограничные случаи. В разработке есть хорошая практика: перед тем как чинить баги, сначала нужно написать тесты, которые их воспроизводят, и только затем уже можно починить их.</p>
7
<p>Какое покрытие считается допустимым? 100% покрытия выглядит красиво, но добиться его невероятно сложно. И для большинства проектов бессмысленно. Затраченные усилия не окупятся. Большинство разработчиков сходится во мнении, что 80% - это достаточно хорошее покрытие. На этом можно и остановиться.</p>
7
<p>Какое покрытие считается допустимым? 100% покрытия выглядит красиво, но добиться его невероятно сложно. И для большинства проектов бессмысленно. Затраченные усилия не окупятся. Большинство разработчиков сходится во мнении, что 80% - это достаточно хорошее покрытие. На этом можно и остановиться.</p>