Тестирование атрибутов ActionFilter с помощью MSpec

Question

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

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

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

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

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

Как мне проверить / проверить это в MSpec?

Answer 1

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

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

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