Зачем издеваться над HttpContext, если его можно построить?

Я всегда каким-то образом подделывал/издевался/заглушал 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.
Но, похоже, это просто не нужно.

С уважением,
Дмитрий.


testing mocking asp.net asp.net-mvc httpcontext
person Dmytrii Nagirniak    schedule 06.11.2009    source источник

Ответы (3)


arrow_upward
5
arrow_downward

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

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

person Levi    schedule 06.11.2009

arrow_upward
2
arrow_downward

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

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

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

person Steve Cooper    schedule 06.11.2009
comment
mocking также отлично подходит для доступа к определенным состояниям ошибок. - person dbn; 01.03.2013

arrow_upward
0
arrow_downward

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

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

Насмешка/заглушка, вероятно, проще.

ИЗМЕНИТЬ

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

Они могут дать лучшее понимание того, что происходит в творении.

Нашел статью, которая также может быть полезна: ASP.NET CreateApplicationHost /SimpleWorkerRequest API-дыра

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

person Marek Tihkan    schedule 06.11.2009
comment
ПУТИ: Я не думаю, что они действительно используются. IIS: Я тоже не думаю, что это нужно. ВРЕМЯ СОЗДАНИЯ: Я полагаю, что оно не должно быть длиннее любого сложного объекта. Но последний пункт (мокап Cache/Request) — хороший. - person Dmytrii Nagirniak; 06.11.2009