как постараться не возвращать насмешки из дразнившего списка объектов
Я испытываю насмешку/ответственность управляемый дизайн. У меня, кажется, есть проблемы, чтобы не возвращать насмешки из насмешек в случае объектов, которым нужен сервис для получения других объектов.
Примером мог быть объект, который проверяет, оплачены ли счета с прошлого месяца. Этому нужен сервис, который получает список счетов. Таким образом, я должен дразнить это billRetrievalService в моих тестах. В то же время мне нужен тот BillRetrievalMock для возврата дразнивших счетов (так как я не хочу, чтобы мой тест полагался на правильность реализации счета).
Мой дизайн испорчен? Существует ли лучший способ протестировать это? Или действительно ли это - способ, которым это должно будет быть при использовании объектов средства поиска (открытие счетов в этом случае)?
примечание стороны: счет althout мог бы быть кандидатом объекта значения, более широкая проблема все еще остается, когда наборы не содержат объекты значения (например, Пользователи).
3 ответа
Мок-возврат моков - это сильный запах кода - возможная проблема с дизайном. Может случиться так, что Bills должны быть объектами с неизменяемыми значениями, над которыми нельзя высмеивать. Или есть некоторая путаница с дизайном и обязанностями классов.
Стоит прочитать книгу Рост объектно-ориентированного программного обеспечения, управляемую тестированием и статью Мнимые роли, а не объекты от изобретателей имитирующих объектов.
Обычно, когда я издеваюсь, у меня получается триада объектов. Первым объектом будет координатор BillsPaidLastMonthCoordinator . Этот объект имеет две зависимости BillRetrievalService и BillPaidValidator .
Вы бы смоделировали две зависимости, и ваш тест был бы для взаимодействия извлечения и передачи счетов на валидацию. Так что для этого теста вам все равно, что это за данные. Это помогает разделить обязанности. Ваш исходный объект отвечал за получение счетов , а затем за проверку того, был ли это оплаченный счет.
То, как вы описали проблему, может оказаться шумным и непростым испытанием. Хрупкость происходит из-за того, что его можно сломать двумя способами.
С помощью коррдинатора его не нужно менять при изменении реализации Bill , только объекты, которые фактически используют Bill . Мой 2centavos.
[РЕДАКТИРОВАТЬ]
Это больше соответствует использованию обработчиков событий (координатор)
Как советует Way of the Testuvius, ни один принцип, каким бы хорошим он ни был, не должен приниматься абсолютно, так же и с правилом, что вам не нужны mocks, возвращающие mocks, есть случаи, когда это вполне подходит.
Как предлагает Гутзофтер, вы можете разбить ваш объект на два, один для собственно валидации, а другой для получения счетов для валидации. Преимущество такого применения принципа "только одна ответственность" заключается в том, что валидатор будет более общим и многократно используемым. С другой стороны, если у вас есть только этот простой случай использования и нет особой необходимости в более высокой многоразовости, то очень прагматично держать получение и валидацию в одном классе. Наслоение, увеличение количества объектов и т.д., не оправданное реальной необходимостью и реальной выгодой, сделанное только ради удовлетворения абстрактного принципа, не является хорошим. Всегда нужно взвешивать все за и против, а реальность редко бывает простой и красивой, как хотелось бы :-) Отличные примеры такого прагматичного подхода можно найти в книге Адама Бьена "Real World Java EE Patterns - Rethinking Best Practices".