Impossible d'examiner les en-têtes de réponse dans les tests unitaires

Question

J'ai un test unitaire pour un gestionnaire Http. Dans ce test, je crée un HttpResponse et de le passer à l'une des méthodes de mon gestionnaire Http.

L'un de mes tests vise à vérifier que les en-têtes de réponse ont été définis correctement :

Assert.AreEqual( "gzip", response.Headers["Content-Encoding"]);

Toutefois, le Headers lance un PlatformNotSupportedException avec le message "Cette opération nécessite le mode pipeline intégré d'IIS". .

Ce qui est étrange, c'est que, si j'ai bien compris, cette exception est liée à réglage les en-têtes de réponse - sans les lire. J'utilise TDD, donc je ne définis pas (encore) les en-têtes, mais j'obtiens toujours l'exception.

Pourquoi est-ce que j'obtiens cette exception et y a-t-il une bonne ou une meilleure façon de tester les en-têtes de réponse ?

Answer 1

A partir de la Documentation de Response.Headers :

Remarques

T avec le mode pipeline intégré d'IIS 7.0 et au moins avec le .NET Framework 3.0. Lorsque vous essayez d'accéder à la propriété Headers et que l'un des éléments suivants est présent, la propriété Headers n'est pas prise en charge. n'est pas remplie, une PlatformNotSupportedException est se produit.

En principe, vous ne pouvez même pas essayer d'y accéder si vous ne remplissez pas ces conditions.

Si j'étais vous, je créerais un constructeur pour votre gestionnaire qui accepterait une valeur de HttpContextBase et utiliser un simulateur afin de tester correctement vos en-têtes.

Answer 2

Je ne suis pas sûr de l'obtention, mais j'ai l'impression que vous n'avez pas de chance. Quant à la question de savoir comment tester unitairement les en-têtes de réponse, eh bien...

Le HttpContext et tous ses dérivés maléfiques sont un problème constant dans le cadre du TDD. Ils veulent que IIS soit là, ils sont scellés pour que vous puissiez les étendre ou vous moquer d'eux. Le mal, le mal, le mal. Ce que nous faisons typiquement avec ces petits crétins est d'écrire notre propre wrapper avec une interface pour eux, comme par exemple IHttpContext. Il suffit alors d'avoir son propre HttpContext et de lui déléguer tous les appels. Ensuite, dans votre application, tout le monde utilise l'interface. Cela résout votre problème d'interaction avec les classes scellées de Microsoft parce que vous pouvez substituer des mocks ou des stubs ou n'importe quoi d'autre.

Quant à savoir comment tester le contexte httpContext concret (ou la réponse ou la requête), je dirais qu'il n'est pas nécessaire de le faire. Microsoft devrait être responsable du test de ses propres classes. Tant que vous testez votre propre interaction avec elle, tout devrait bien se passer.