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