Контроллер проверяет кровотечение на моделях?

Question

Я пишу некоторые тесты с RSpec (тесты, а не спецификации, код до сих пор не тестировался) и наткнулся на неопределенность ...

Я хочу знать, правильно ли контроллер вызывает методы модели, и я разделен между возможностями:

• тестирование контроллера с использованием метода модели (я не буду знать, существует ли метод модели на самом деле или принимает приведенные аргументы)
• оставьте метод модели незапертым и рискует, что мои тесты контроллера попадут на территорию тестирования модели (а также сделайте их медленными из-за доступа к БД и дорогостоящих методов)
• написать несколько тестовых контроллеров, каждый из которых не помечает один метод модели (все еще медленный, как ад, но, по крайней мере, многословный)

Есть ли правильный ответ на этот вопрос?

Answer 1

Я довольно поздно на вечеринку. Но полностью согласен с Solnic и не согласен с Arsen7.

Подумайте об этом:

• Если вы используете ванильные методы активной записи, например, MyModel.find_by_id (123) вы можете смело заглушить, что, поскольку AR уже хорошо протестирован, нет необходимости в его базе данных.

• Если вы вызываете пользовательский метод, который вы определили в модели, например, MyModel.foo (param1, param2), тогда вы все равно должны смоделировать / заглушить его, потому что у вас должен быть тест на это в вашей спецификации MyModel.

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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