asp.net mvc rhino высмеивает насмешливые значения httprequest - PullRequest
1 голос
/ 07 июля 2010

Привет. Есть ли способ смоделировать параметры запроса, каков наилучший подход при тестировании для создания поддельных значений запроса для запуска теста

что-нибудь понравится этой работе?

        _context = MockRepository.GenerateStub<HttpContext>();
         request = MockRepository.GenerateStub<HttpRequest>();

        var collection = new NameValueCollection();
        collection.Add("", "");

        SetupResult.For(request.Params).Return(collection);
        SetupResult.For(_context.Request).Return(request);

Ответы [ 4 ]

1 голос
/ 07 июля 2010

Как уже говорилось, вы действительно не хотите иметь слишком много прямых зависимостей от HttpRequest, так как это довольно плохой дизайн в наше время. Этот факт отметил, что вы должны взглянуть на макет HttpRequestBase, так как он использует виртуальные методы, дружественные к носорогам.

0 голосов
/ 05 января 2011

Я попытался создать новый экземпляр объекта HTTPRequest и смог это сделать.Входные данные, такие как Text Writer, должны быть смоделированы через httpcontextbase или другим способом.

0 голосов
/ 07 июля 2010

Посмотрите в MVCContrib.TestHelper. Он использует Rhino.Mocks для создания полной среды тестирования для контроллеров (макет HttpContext, Request, Response, Session и т. Д.). См .: Как использовать Rhino.Mocks для насмешки над ControllerContext

0 голосов
/ 07 июля 2010

HttpRequest содержит массу не виртуальных свойств и методов. Вы никогда не будете в состоянии высмеивать это. Если вы обращаетесь к нему из Page.Request, вы даже не можете создать новый экземпляр и установить его значения для своего теста. Это одна из причин того, что пользовательский интерфейс редко (если вообще) получает автоматические тесты; это часто просто невозможно. Вот почему мы используем шаблоны, которые допускают автоматическое тестирование, такое как MVC и MVVM: передавая как можно больше логики обработки в отдельный класс, который является тестируемым, мы сокращаем количество ручного тестирования, которое нам нужно сделать.

Лучшая ставка, которую вы можете сделать, - создать класс, который вы можете макетировать (т. Е. С помощью виртуальных методов или спортивных состязаний и использовать как интерфейс) и получать доступ только к HttpRequest через этот класс.

Например, если вы хотите получить определенные значения файлов cookie в рамках обработки вашей страницы, вы можете создать класс CookieHandler следующим образом:

public class CookieHandler
{
    private HttpRequest CurrentRequest;

    public CookieHandler(HttpRequest request)
    {
        CurrentRequest = request;
    }

    public virtual HttpCookie UserLanguagePreference
    {
        get
        {
             return CurrentRequest.Cookies["UserLanguagePreference"].Name;
        }
    }
}

Это не идеальный класс, это просто для примера; поскольку UserLanguagePreference является виртуальным, он может быть осмеян носорогом. Вы можете сделать CookeHandler синглтоном (заменяемым в ваших тестах), можете использовать инъекцию на основе свойств на своей странице пользовательского интерфейса или использовать инфраструктуру DI, такую ​​как Unity.

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

...