2015-02-09 3 views
2

У меня есть класс фасада, который реализует следующий метод: getTotalNumOfItems(Query query). Фасад стоит перед двумя другими классами обслуживания, которые реализуют тот же метод. В зависимости от типа параметра query, фасад определяет, следует ли делегировать одну из служб или другую.Тестирование модуля класса фасада

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

Я предоставил на месте макетные версии двух сервисов, используя Mockito. Однако, когда я пишу для этого единичный тест, единственное, что я могу проверить, это «проверить, возвращает ли фасад число, равное тому, что возвращает один из mocks (в зависимости от типа запроса)». Кажется, что нет способа протестировать фасад таким образом, что он более агностик.

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

+0

Вам необходимо проверить отдельные объекты обслуживания, а не сам фасад. – SMA

+0

Так я и сделал. Тем не менее, я хочу быть уверенным, что фасад всегда решает на правильном обслуживании делегировать – preslavrachev

+0

Нет, вы не должны больше не делать UT. UT - это только класс и конкретный метод. – SMA

ответ

4

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

Смежные вопросы