Java: извлечение интерфейсов только для тестирования

Question

Я хочу протестировать свой код, но заметил, что некоторые классы бизнес-логики требуют много объектов с большим количеством состояний. Но на самом деле связь между этими классами ограничена 1 или 2 методами.

Это хороший стиль, если я создаю интерфейс с этими двумя методами и в моем тесте просто создаю фиктивный объект, который ничего не делает?

В этом коде будет больше интерфейсов, которые на самом деле не нужны, поэтому я не уверен, что это хорошая идея?

Answer 1

Хотя наличие интерфейсов - хорошая идея, вам не нужны интерфейсы, чтобы делать макеты.EasyMock, Mockito и PowerMock - все они позволяют имитировать конкретные классы.Поэтому, учитывая, что вы можете оставить код как есть и использовать Mockito (мой личный фаворит), чтобы высмеивать внедренные классы.

К вашему сведению, насмешки не должны "ничего не делать".Они должны быть проверены с каждым возможным возвращаемым значением и сгенерировано каждое возможное исключение.

Answer 2

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

Answer 3

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

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

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