Ответ
Я не придерживаюсь жесткого единого процента для всего проекта. Моя практика основана на разумном подходе, где важнее качество тестов, чем их количество.
Обычно я стремлюсь к следующему:
- Критичная бизнес-логика и ядро приложения (Domain Layer): Цель — 90%+ покрытия модульными тестами. Это расчеты, алгоритмы, правила предметной области.
- Сервисный слой (Application Layer): Здесь много интеграций. Я фокусируюсь на интеграционных тестах для ключевых сценариев, покрытие может быть 70-80%.
- Контроллеры, API-эндпоинты: Пишу сквозные (E2E) или интеграционные тесты для основных путей выполнения (happy path, ошибки валидации). Процентное покрытие здесь менее показательно.
- Инфраструктурный код (база данных, внешние API): Часто используется мокирование или тесты с тестовой БД (например, Testcontainers). Покрываю основные сценарии взаимодействия.
Пример настройки отчета о покрытии в .NET (coverlet + ReportGenerator):
<!-- В .csproj файле тестов -->
<ItemGroup>
<PackageReference Include="coverlet.collector" Version="6.0.0" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.8.0" />
</ItemGroup># Запуск тестов с сбором покрытия и генерацией отчета
dotnet test --collect:"XPlat Code Coverage" --results-directory ./TestResults
reportgenerator -reports:"./TestResults/**/coverage.cobertura.xml" -targetdir:"./CoverageReport" -reporttypes:HtmlЯ всегда исключаю из метрик покрытия автоматически сгенерированный код, DTO и простые свойства. Главный критерий — уверенность в том, что изменения в коде не сломают существующую функциональность, которую проверяют тесты.