Существует риск быть несправедливым по отношению к вашим коллегам при ответе на ваш вопрос, потому что вы не предоставите конкретный пример кода c для обсуждения. Поэтому, безусловно, есть вероятность того, что ваши коллеги действительно переборщят с юнит-тестированием, как и ваше мнение о нем, но также возможно, что они делают это правильно.
Однако, это также мое наблюдение что есть определенные люди, которые, вообще говоря, пытаются справиться с трудностями в искусстве создания программного обеспечения (включая тестирование, а также множество других действий), устанавливая простые правила. Поскольку обычно предписываемые правила дают хорошее руководство для определенной части случаев, для этого требуются определенная уверенность в себе, опыт, воля и способность выступать против них в тех случаях, когда правила слишком просты c.
Говоря о покрытии кода, чем больше, тем лучше, верно? По крайней мере, многие люди сначала думают так. На этом этапе они могут даже не знать, что существуют разные критерии покрытия (покрытие выписки, покрытие филиала, ...). Они могут даже не иметь четкого понимания, что отличает модульное тестирование от тестирования взаимодействия (интеграционное тестирование) и подсистемного тестирования (компонентное тестирование или функциональное тестирование). Только если вы приобретете больше опыта и если вы заинтересованы в расширении своих знаний о методологии тестирования, вы узнаете все больше и больше и, возможно, в какой-то момент времени поймете, какой подход будет наиболее полезным.
Но, даже если вы достигнете этой точки, вы все равно должны быть готовы спорить с теми, кто установил организационные или проектные правила в первую очередь: это часто достаточно сторон, которые не имеют большого практического опыта в разработке программного обеспечения, например, клиенты или люди обеспечения качества. Чтобы убедить этих людей в том, что выбранные ими правила не подойдут ни в этом, ни в другом случае, нужно многому их научить, что требует определенных усилий, а иногда может оказаться совершенно бесполезным, если они не заинтересованы в расширении своих знаний.
Но, даже если в какой-то момент они согласятся с вашей точкой зрения и примут, что в вашем случае с исключением все в порядке, они не решаются ослабить или уточнить правила: часто эти стороны рассматривают группу разработчиков как группу дебилов, которые Только путем установления строгих правил можно доверять написанию программного обеспечения, которое не содержит ошибок из-за нарушения основных правил. Например, люди пишут только несколько юнит-тестов или вообще никаких юнит-тестов, если только вы не установите для каждого цель с высоким уровнем охвата. И, к сожалению, их опыт доказывает, что они правы в этом.
Возможно, эти строки кажутся немного пессимистичными c. Каково решение? Решением является организация, которая серьезно относится к качеству и понимает, что сущность качества программного обеспечения (в вашем случае качество тестирования) принципиально отличается от выполнения простых критериев metri c или следования простым правилам. Чтобы тесты были высокого качества, организация должна быть готова правильно инвестировать в тестирование, обеспечивая, чтобы все стороны понимали соответствующие цели различных видов тестов, и чтобы разработчики и тестировщики спорили о тестовых примерах, о том, как тестовый код написано et c. «Разработка программного обеспечения на основе правил» должна быть преобразована в «разработку программного обеспечения, основанную на понимании», но такое преобразование сложно.