Вы не можете, и, честно говоря, вы не должны .Требования к покрытию произвольного кода ужасны, потому что покрытие кода метрика .Он дает вам информацию, которая может быть полезна, когда воспринимается как большая картина, но сам по себе ничего не говорит.
Вот единственное, что покрытие кода может вам однозначно сказать: "Какой кодне тестируется вообще? "
Наличие 80% покрытия кода не говорит вам " У меня 80% без ошибок код " или" 80%мой код является функционально правильным".Он говорит вам: " Кто-то написал какой-то тестовый код, который затрагивает 80% моего кода. " Не то, чтобы тесты были правильными, хорошими или содержали утверждения, которые имеют смысл и подтверждают правильное поведение.
Размещение произвольного процента покрытия кода в качестве требования не имеет значения.Если команда еще не знакома с хорошими практиками тестирования и написанием хороших тестов для нового кода, они просто обыграют число.Вы можете написать тестовый метод, который будет запускать некоторый код, не делать никаких утверждений и сообщать об очень высоком числе покрытия кода.
Если команда уже работает с хорошими методиками тестирования, им не нужно строить, чтобы на них кричать, если охват падает до 79%.Может быть, они добавили что-то с помощью тонны сгенерированного инструментами «дизайнерского» кода, который не нуждается в тщательном тестировании.
Все это говорит о том, что SonarQube (и я уверен, что другие инструменты) позволяют вам определять качественные ворота (включая требуемые номера покрытия кода) и неудачные сборки, если они не соответствуют этим критериям качества.