Тестирование ActionFilterAttributes с MSpec

Question

В настоящее время я пытаюсь понять MSpec, в основном, чтобы узнать новые способы (T/B) DD, чтобы иметь возможность принять обоснованное решение о том, какую технологию использовать. Раньше я в основном (только читал) использовал встроенную структуру MSTest с Moq, поэтому BDD для меня совершенно новый.

Я пишу приложение ASP.NET MVC, и я хочу реализовать PRG. В прошлый раз, когда я это сделал, я использовал фильтры действий для экспорта и импорта ModelState через TempData, так что я мог бы вернуть RedirectResult, и ошибки проверки все равно будут присутствовать, когда пользователь получит представление. Я проверил, что сценарий, проверив две вещи:

а) То, что ExportModelStateAttribute я написал был применен (среди тестов для моего контроллера)
б) атрибут работал (среди тестов для фильтра действия атрибутов)

Тем не менее, в BDD я понял, что меня еще больше беспокоит поведение, а тем более - реализация. Это означает, что я должен, вероятно, просто проверить, что состояние модели находится в tempdata, когда действие завершило выполнение - не обязательно, что это делается через атрибут.

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

Как я должен специфицировать/проверить это в MSpec?

Answer 1

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

Вы все еще можете выразить желаемое поведение в тестах вашего контроллера (состояние модели хранится во временных данных), но тест может утверждать существование атрибута (может быть, он может быть инкапсулирован в поведении, возможно?).

В стороне: ASP.NET MVC разработан с соглашением о возврате представления, если состояние модели содержит ошибки. Использование PRG в этих сценариях имеет смысл, поскольку PRG предназначена для прекращения подачи и обработки повторяющихся форм (то есть действительного запроса). Когда пользователь отправляет недопустимую форму, вы проверяете наличие ошибок до того, как начнете обработку запроса, поэтому прекратите обработку запросов пользователей.