Если я тестирую сервисную оболочку, должен ли я абстрагироваться от всего? - PullRequest
Новая
       19

Если я тестирую сервисную оболочку, должен ли я абстрагироваться от всего?

0 голосов
/ 28 февраля 2012

У меня есть класс менеджера сервисов, используемый для абстрагирования моих звонков из моего MVC-проекта в мой REST-сервис.Все, что делает класс диспетчера, - это устанавливает вызовы Rest (используя RestSharp) и возвращает служебные данные обратно в приложение MVC.

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

Однако, здесь моя дилемма.Как далеко я должен абстрагировать вещи только для того, чтобы я мог тестировать изолированно?

Итак, мой RestClient вводится MVC в мой класс менеджера.Я разрешаю инжектору MVC установить базовый URL.Со всем этим у меня все в порядке, но вот вопросы, которые у меня есть:

  • Должен ли мой метод принимать параметр (userId) и IRestRequest?
    • Моя проблема с этим заключается в том, что мой универсальный менеджер сервисов внезапно станет специфичным для отдыха, поскольку мой интерфейс должен будет включать оба параметра.
  • Если я не введуIRestRequest в метод и позволить реализации создать его, это нормально, так как это будет проигнорировано, поскольку основным тестируемым методом является RestClient.Execute, который будет заглушен и не заботится о реальном RestRequest?
    • На самом деле, поскольку это является частью реализации, я мог бы смутить и убедиться, что метод Execute отправляется в соответствующий объект RestRequest?
  • Или,я не должен вводить IRestRequest, а вместо этого вводить IRequestResolver в мой конструктор?Затем в своем методе я могу просто использовать IRequestResolver, который будет принимать строку, представляющую метод.Затем он будет использоваться для определения параметров RestRequest и возврата объекта RestRequest, заполненного соответствующим образом для метода?
  • Или я должен просто выполнить подпункт под моим первым маркером и использовать конкретную реализацию.
  • Какие-либо другие варианты, которые мне не хватает?

Я склоняюсь к четвертой пуле, когда она достигает фактического тестируемого решения?

Дайте мне знать, еслиВам нужно больше подробностей, чтобы помочь мне решить мою дилемму.

Ответы [ 2 ]

1 голос
/ 29 февраля 2012

Я хорошо знаю эту дилемму;и были здесь несколько раз.

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

Пока я писал это, я видел ваш собственный ответ;и я полностью согласен.

Пока вы можете проверять предположения и тестировать поведение, вы делаете достаточно;как вы говорите - вам нужно только проверить, что все изменилось, и вы сами знаете границы своего собственного контекста - изменится ли когда-либо провайдер реально?Нет - не абстрагируйтесь.

Недавно я разработал несколько масштабных решений Microsoft Dynamics CRM для моего работодателя;в конечном итоге мои тесты предполагают, что CRM API в порядке, и они просто проверяют поведение моих оболочек.

В любом случае, это всего лишь приблизительный шаг, как я вижу, я надеюсь, что это имеет какое-то значение для вас!

1 голос
/ 29 февраля 2012

Обсудив это с другом, я решил использовать конкретную реализацию.

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

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

...