Почему mock HttpContext, если он может быть построен?

Question

Я всегда фальсифицировал/издевался/ступил HttpContext как-то в ASP.NET (намного проще в ASP.NET MVC/MonoRail).

Но я вижу, что сам HttpContext может быть построен легко, буквально с помощью пары строк кода.

var tw = new StringWriter(); 
var workerReq = new SimpleWorkerRequest("/webapp", @"c:\here\there\wwwroot", "page.aspx", tw); 
var context = new HtpContext(workerReq); 

Если мы будем обернуть этот код в то вроде этого он должен работать нормально, и, вероятно, мы можем даже сделать ASPX с помощью этого:

using(Simulate.HttpContext()) { 
    HttpContext.Current.BlaBla; 
} 

Так вопросы:

1. Причины, по которым это НЕ должно быть сделано.
2. Причины, по которым это ДОЛЖНО быть сделано.
3. Почему он не широко используется (на самом деле я не помню ЛЮБЫЕ сообщения об этом).

Я помню одно сообщение, где Фил Хаак построил HttpContext, используя Reflection hacks.
Но, похоже, это просто не нужно.

Cheers,
Dmitriy.

Answer 1

Это очень хорошо для проведения очень простого тестирования, но как вы можете протестировать компонент, который использует HttpRequest.Files? Насколько я знаю, нет общедоступных API, которые позволят вам указать это на SimpleWorkerRequest. Даже если вы можете найти место, где вы можете установить свойство HttpFileCollection, обратите внимание, что его конструктор является внутренним, поэтому вы даже не можете создать экземпляр этого типа.

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

Answer 2

Существует несколько сценариев для рассмотрения.

Сценарий первый: вы тестируете устройство. у вас есть что-то маленькое, как класс, который управляет доступом к кешу и который явно вызывает HttpContent.Cache. В этом случае высмеивайте контекст, чтобы вы могли видеть, какие вызовы выполняются, и работают ли они, как вы ожидаете.

Сценарий 2. Вы проводите интеграционный тест, где вы пытаетесь проверить что-то большое, например, создание сложной страницы. В этом случае дайте ему реальный объект HttpContent так, как вы его нашли. Ваш интеграционный тест лучше имитирует реальное время выполнения.

Answer 3

Это может работать, но ...

• Во-первых, я вижу некоторые пути, которые могут быть различными в средах.
• Во-вторых, ему нужно что-то вроде установки IIS?
• Сколько времени требуется для его создания? Если у меня есть 100 тестов, которые нуждаются в нем, и это занимает 1 секунду, то это означает, что мой тестовый запуск примерно через минуту или дольше, и это приводит к тому, что разработчики будут тестировать меньше.
• Как легко вы можете издеваться/настраивать кэш, запрос и т. Д. Для создания тестового сценария?

Сделка/укупорка, вероятно, проще.

EDIT

Найдено некоторые исходный код для HttpContext и SimpleWorkerRequest в проекте Mono:

• SimpleWorkerRequest.cs
• HttpContext.cs

Те могут дать более полное представление о том, что происходит в создании ,

нашел статью, что может быть полезно, так: ASP.NET CreateApplicationHost/SimpleWorkerRequest API Hole

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