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

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

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

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

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

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

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


asp.net-mvc bdd action-filter mspec
person Tomas Aschan    schedule 20.05.2010    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

person Neal    schedule 31.05.2010
comment
В ПОРЯДКЕ. Итак, в основном вы рекомендуете, чтобы я определил поведение, которое говорит store_model_state_in_temp_data, но на самом деле просто проверяет, применяется ли атрибут, а затем определяет тесты для атрибута в совершенно другом тестовом контексте? - person Tomas Aschan; 03.06.2010
comment
да. Вы проверяете ожидаемое поведение (что) много раз и реализацию этого поведения (как) один раз. - person Neal; 04.06.2010
comment
В ПОРЯДКЕ. Теперь следующая проблема: в моем старом способе проверки применения атрибута я использовал отражение и передал выражение и тип методу тестирования. При указании поведения я не могу понять, как передать эти аргументы. (Тип можно определить, просто сделав класс поведения универсальным или что-то в этом роде, но мне все равно нужна лямбда...) Как мне это сделать? - person Tomas Aschan; 11.06.2010
comment
В Install получите MethodInfo действия, которое вы тестируете. В Потому что получите набор атрибутов, примененных с помощью GetCustomAttributes. В спецификации утверждают, что коллекция не должна быть нулевой длины. - person Neal; 14.06.2010
comment
Нил прав. Атрибуты являются сквозными проблемами, но вы можете проверить их с помощью отражения в вашем контексте BDD. - person eduncan911; 21.07.2010