Wrapper-Classes для Unit-Tests

Question

Я могу написать некоторые Unit-Tests и с этим Рефакторингом. Мы используем Hybris. То, что вы можете видеть очень часто, это Trainwrecks. Например: cmsSiteService.getCurrentSite().getSlaveSalesOrganization() и так далее.

Теперь, записывая Unit-Tests и издеваясь над ответами, я бы в этом случае сначала высмеял CurrentSite и объявил doReturn(currentSite).when(cmsSiteService.getCurrentSite), а затем doReturn(slaveSalesOrganization).when(currentSite).getSlaveSalesOrganization().

Этот пример довольно короткий, но с cmsSiteService это происходит по всему проекту. Поскольку cmsSiteService является сторонним классом Hybris, я подумал, что было бы неплохо написать класс-оболочку, который наследует все от CMSSiteService-Class. Там я могу написать метод getSlaveSalesOrganizationFromCurrentSite (CMSSiteService cmsSiteService), где я бы назвал все выше.

Это рекомендуется или есть лучшее решение по умолчанию?

Answer 1

Звучит так, будто вы на правильном пути. То, что вы делаете, - это рефакторинг вашего кода, чтобы лучше придерживаться Law of Demeter, также известного как «принцип наименьшего знания». Выкапывание цепочки объектов, как вы говорите, является анти-шаблоном именно по той причине, по которой вы столкнулись: когда объекты плотно связаны, их трудно модифицировать и тестировать.

В идеале вы бы добавили метод getSlaveSalesOrganizationFromCurrentSite в ваш класс CMSSiteService, если вам разрешено изменить этот код. Я думаю, что создание обертки для упрощения уродливого интерфейса - отличный второй вариант. Это будет реализация Adapter pattern. Это отличный способ не допустить, чтобы ваш собственный код был тесно связан с (чужим) дерьмовым кодом.