Les meilleures pratiques pour HttpContext et contrôleurs testables dans ASP.Net MVC

Question

Mise à jour:

Basé sur deux des réponses que je l'ai reçu, je veux simplement préciser que je suis bien conscient comment s'y moquant HttpContext en utilisant un cadre de simulation. Je suis plus intéressé de savoir quels sont les avantages et les inconvénients de moquer HttpContext par rapport à l'utilisation de classes wrapper autour de HttpContext.

---

Je cherche des opinions sur la façon de traiter HttpContext lors de la construction des contrôleurs testables dans ASP.Net MVC. Après avoir lu cela, il semble y avoir deux écoles de pensée - soit construire à partir de HttpContextBase et utiliser un cadre moqueur pour générer les stubs/mocks nécessaires pour vos tests unitaires ou construire des classes wrapper agnostique autour des zones de HttpContext que vous avez l'intention d'utiliser .

En ce moment je penche vers la construction de HttpContextBase. Il semble que ce soit à la fois le processus de développement le plus rapide et le plus facile à gérer, car vous n'avez pas besoin de passer du temps à développer et à gérer des classes wrapper supplémentaires. Je peux voir comment les classes wrapper peuvent être bénéfiques car elles éliminent l'implémentation sous-jacente et gardent le contexte du contrôleur séparé de la requête - mais je ne suis pas sûr que cela vaut la surcharge supplémentaire à installer et à maintenir.

Selon vous, quels sont les avantages et les inconvénients entre ces deux approches et quand choisiriez-vous l'une par rapport à l'autre? Y a-t-il certains types de développement qui se prêtent mieux à l'une des solutions que l'autre?

Étant donné que cela semble être un problème commun à la plupart des équipes qui testent et utilisent ASP.Net MVC, comment avez-vous fait pour résoudre ce problème? Si vous avez résolu ce problème, comment fonctionnait votre solution et que feriez-vous différemment maintenant?

Answer 1

Je suis penché vers HttpContextBase. Principalement parce que je pense qu'il a été inventé pour cette raison: la testabilité. Et pourquoi réinventer la roue quand il existe déjà une solution acceptable?

Si vous mettez beaucoup d'efforts dans vos classes wrapper autour HttpContext, vous finiriez avec quelque chose de très similaire à HttpContextBase ...

Answer 2

Pour tester, j'utilise Rhino.Mocks. Pour configurer le HttpContext dans le contrôleur, je me suis simplement moqué de lui. Donc, mon système sous test (ou SUT) est quelque chose comme:

  Controller controllerBase = sut as Controller; 

je me moque ensuite le contexte du contrôleur, et mis en place le contexte du contexte du contrôleur pour revenir la maquette de la classe HttpContextBase (comme je l'ai mentionné ci-dessus). Mon code ressemble à quelque chose comme:

controllerContext = AMockOf<ControllerContext>(); 

// Add the test HttpContextBase to the controller context 
HttpContextBase httpContextBase = SetUpTestHttpContext(); 
WhenThe(controllerContext).IsAskedForIts(x =>x.HttpContext).Return(httpContextBase).Repeat.Any(); 

Pour d'autres objets, j'utilise parfois des contrefaçons.