Pourquoi maquette HttpContext si elle peut être construite?

Question

Je l'ai toujours fait semblant / se moquant / stubbing HttpContext en quelque sorte dans ASP.NET (beaucoup plus facile dans ASP.NET MVC / monorail).

Mais je vois que HttpContext lui-même peut être construit facilement, littéralement avec quelques lignes de code.

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

Si nous terminerons ce code dans quelque chose comme cela, il devrait fonctionner correctement, et probablement nous pouvons même rendre ASPX à l'aide que:

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

Ainsi, les questions sont les suivantes:

1. Les raisons pour lesquelles il ne devrait pas être fait.
2. Les raisons pour lesquelles il faut le faire.
3. Pourquoi est-il pas largement utilisé (en fait, je ne me souviens pas de postes à ce sujet).

Je me souviens d'un poste où Phill Haack construit HttpContext en utilisant hacks de réflexion.
Mais il semble qu'il est tout simplement pas nécessaire.

Cheers,
Dmitriy.

Answer 1

Il est très bien pour faire des tests très simple, mais comment l'unité vous tester un composant qui utilise HttpRequest.Files? Pour autant que je sais qu'il n'y a pas d'API publiques pour vous permettre de spécifier ce sur SimpleWorkerRequest. Même si vous pouvez trouver un endroit où vous pouvez définir une propriété HttpFileCollection, notez que son constructeur est interne, de sorte que vous ne pouvez même pas créer une instance de ce type.

HttpRequest.Files est pas seul à cet égard, et en fait il y a probablement des choses beaucoup plus que vous ne peut pas tester avec la mise en œuvre HttpContext actuelle que vous peut Test . C'est là des abstractions sont vraiment utiles.

Answer 2

Il y a deux scénarios à considérer.

Premier scénario: Vous êtes des tests unitaires. vous avez quelque chose de petit, comme une classe qui gère l'accès au cache, et qui HttpContent.Cache appels explicitement. Dans ce cas, se moquer du contexte afin que vous puissiez voir ce que les appels sont faits, et qu'ils travaillent la wy que vous attendez.

Scénario deux: Vous faites un test d'intégration, où vous essayez de tester quelque chose de grand comme la génération d'une page complexe. Dans ce cas, donnez-lui l'objet réel HttpContent la façon dont vous avez trouvé. Votre test d'intégration permettra de mieux simuler l'exécution réelle.

Answer 3

Cela pourrait fonctionner, mais ...

• Tout d'abord, je vois des chemins, qui peuvent être différents dans des environnements.
• Ensuite, il ne faut quelque chose comme IIS installé?
• Combien de temps qu'il faut pour créer? Si j'ai 100 tests qui en ont besoin et il faut 1 sec, alors cela signifie que mon essai sur les minutes ou plus longtemps et il conduit aux développeurs de tests en cours d'exécution moins.
• Comment vous pouvez facilement se moquer / Cache d'installation, demande etc pour la création scénario de test?

Mocking / stubbing est probablement plus facile.

EDIT

Trouver un code source pour HttpContext et SimpleWorkerRequest dans le projet Mono:

• SimpleWorkerRequest.cs
• HttpContext.cs

Ceux-ci peuvent donner un meilleur aperçu de ce qui se passe dans la création.

trouvé un article qui pourrait être utile aussi bien: ASP API .NET CreateApplicationHost / SimpleWorkerRequest trou

Cela illustre bien fait que nous avons besoin de comprendre ce qui se passe dans les objets avant de les appliquer et il faut du temps. Mocking semble plus facile.