Модульное тестирование всех контроллеров из одного теста - PullRequest
1 голос
/ 23 сентября 2010

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

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

Разумно ли создавать модульный тест, который будет работать с несколькими контроллерами? Кто-нибудь может поделиться кодом из подобного теста, который оказался полезным?

РЕДАКТИРОВАТЬ: Просто понял, что тестирование фильтра действий может быть проблематичным. Тем не менее, если у вас есть мысли, чтобы поделиться на массовое тестирование контроллеров ...

Ответы [ 3 ]

3 голосов
/ 23 сентября 2010

Не рекомендуется тестировать более одной вещи одновременно в тестах.

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

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

ОТВЕТ НА ВАШЕ РЕДАКТИРОВАНИЕ

Проверка фильтров может быть достигнута путем отделения фильтра от атрибута. Вот пример: класс LoadMembershipTypeListFilter имеет «швы», необходимые для использования тестовых подделок. Вот где ваша логика в вашем фильтре должна быть проверена.

public class LoadMembershipTypeListFilter : IActionFilter
{
    private IMembershipTypeProvider _provider;
    private IMembershipTypeAdminMapper _mapper;

    public LoadMembershipTypeListFilter(IMembershipTypeProvider provider, IMembershipTypeAdminMapper mapper)
    {
        _provider = provider;
        _mapper = mapper;
    }

    #region IActionFilter Members
    public void OnActionExecuted(ActionExecutedContext filterContext)
    {
    }

    public void OnActionExecuting(ActionExecutingContext filterContext)
    {
        //implementation...
    }
    #endregion
}

И атрибут здесь использует фильтр, в этом примере разрешаются зависимости, требуемые фильтром, при вызове локатора службы:

public class LoadMembershipTypeListAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var filter = new LoadMembershipTypeListFilter(IocResolve.Resolve<IMembershipTypeProvider>(), IocResolve.Resolve<IMembershipTypeAdminMapper>());
        filter.OnActionExecuting(filterContext);
    }
}

И ваш контроллер использует атрибут:

[LoadMembershipTypeList]
public ActionResult Create()
{
    return View();
}
2 голосов
/ 23 сентября 2010

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

1 голос
/ 23 сентября 2010

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

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

Если вы хотите протестировать фильтр действий, идите прямо против него.Возможно, вам действительно нужно убедиться, что различные результаты / модели работают с фильтром.

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