Модульные тесты классов связи

Question

У меня есть класс, используемый для обработки соединения с внешней системой. Класс имеет некоторые несколько общих методов, скажем:

• близко()
• Configure()
• Send()
• подключения()

и несколько частные методы. Класс предназначен для скрыть большую часть восстановления, проверки отказа и обработки соединений во внутренних работах.

Теперь я получаю ошибку покрытия кода, так как для этого класса нет модульных тестов, кроме метода configure.

• Есть ли другой способ написания модульных тестов для таких классов, за исключением тяжелых насмешек?
• Если да, то разве это не хорошее доказательство, что класс должен быть протестирован на уровне тестирования интеграции или тестирования системы, а не на модульном тесте? Связаны ли классы общения с модульными тестами или системными тестами?

Answer 1

Если вы не можете создать экземпляр внешней системы локально в модульном тесте, эта задача является классической интеграцией или системным тестом. Таким образом, классы связи, как правило, не относятся к модульным тестам.
Покрытие будет низким для таких классов, показывая, что есть , чтобы проверить их в противном случае.

Далее отчет о покрытии, например, в SonarCube, можно (можно надеяться) отфильтровать. Можно определить фильтры исключений вместе с ответственным лицом (например, Software Architect.)
Это может помочь переместить все такие классы связи в собственный пакет. Или даже для собственного проекта или файла jar. Для этого проекта покрытие тогда не будет выполнено.

Иногда имеет смысл построить внешнюю внешнюю систему, с которой можно работать. Если внешняя система еще находится в разработке и когда она ежедневно меняет свои интерфейсы, вы можете потерять много времени при использовании внешней системы. В таких ситуациях может использоваться фиктивная система, которая, возможно, также возможна из модульного теста.

Answer 2

Это зависит от количества кода в классе. Если он просто настраивает другую службу (например, сокет или драйвер базы данных), модульное тестирование не имеет смысла, поскольку кто-то, вероятно, уже протестировал фактический сервис.

Если код очень сложный (обработка ошибок, преобразование данных), вы должны написать модульные тесты для этой части кода и высмеять сервис.