Как было написано в комментариях, единого числа не существует, поскольку оно зависит от кода.
Для автоматически сгенерированного кода процент может даже составлять 0% - конечно, генератор кода должен быть проверен (так же как фрагменты кода, используемые генератором), плюс исходный файл, который управляет генератором. Но, если все это будет сделано, модульное тестирование сгенерированного кода может не принести никакого дополнительного значения.
Иногда вводится код-обертка, чтобы отделить компонент от его зависимостей. Обертки предназначены для насмешки, но не для проверки на единицу.
Код устойчивости (например, регистр по умолчанию в операторе switch, который уже явно охватывает все случаи) не может быть разумно проверен модулем, потому что он недоступен.
Некоторый код состоит только из взаимодействий и поэтому должен быть проверен на интеграцию, а не на модульном тесте.
Некоторый код (можно утверждать) слишком тривиален, чтобы приводить какие-либо значения при тестировании модулей.
Установка целей покрытия также сопряжена с некоторыми рисками:
Так как легче покрыть тривиальный код, вы можете получить, скажем, 80% покрытия кода, где тривиальные 80% кода покрыты, но ужасно сложно (и, следовательно, также вероятно, глючит) 20% кода нет. И покрытие 80% дает вашему руководству ложное представление о низком риске.
Даже покрытый код может быть плохо протестирован. Он даже не может быть проверен вообще - только выполнен, без оценки результатов.
К сожалению, качественная организация редко принимает такие аргументы. Что, с другой стороны, понятно, потому что разработка достаточно часто откладывает качественные действия, чтобы быть в состоянии уложиться в сроки клиента.
Наилучшим подходом было бы иметь одного или нескольких инженеров по качеству (не менеджеров по качеству) в проекте, которым доверяет организация по качеству, но с другой стороны не просто смотреть на процент покрытия , но при истинном качестве тестовых комплектов.