Вы находитесь на правильном пути, но вы не перемещаете проблему где-то в другом месте - вы изолируете ее, чтобы эта проблема не протекала по всей вашей базе кода и другим тестам. Я бы рассматривал это только как проблему, если вы допустили неверные предположения об обернутом поведении или игнорировали доказательства этих предположений. Требуется некоторое тестирование, но с разной степенью сложности. Как далеко вы решите протестировать эти предположения, это будет компромисс, который вам нужно сделать.
Для некоторых сценариев обертка может быть протестирована, но для этого потребуются физические зависимости. Например, статический метод, который изменяет файл, потребует, чтобы вы потратили время на установку файловой системы или вспомогательный класс, который загружает файл с веб-сервера. Мне нравится думать об этих тестах как «интеграционных тестах» вместо «модульных тестов», поскольку они действуют на их зависимости вместо того, чтобы работать изолированно. Поскольку эти тесты могут занять больше времени для выполнения стандартных тестов, вы можете исключить их и запустить их менее часто, чем ваши более быстрые модульные тесты.
Для других сценариев вы, возможно, не сможете написать тест без значительных усилий. Например, вы могли бы обернуть логику, которая показывает диалог в отдельном окне - проверка этой логики в коде будет много работать, но запуск приложения и проверка его работы могут быть достаточно. Вы попадете в зону покрытия кода, но для меня это приемлемый компромисс.
Основная проблема заключается в понимании допущений обернутого поведения - например, какой тип исключения выбрасывается с удаленного сервера, если веб-запрос искажен или сетевое соединение потеряно? Если вы не правильно зафиксируете эти допущения, эти ошибки перейдут в другие области вашего кода.