2009-08-20 7 views
1

J'ai mon objet Fake pour HttpRequest prêt (un wrapper et une interface) ... puisque je n'ai pas besoin d'appeler un constructeur, comment passer dans le faux HttpRequest sans casser l'interface de cette méthode?Comment tester unitairement une méthode statique en utilisant un faux objet pour la dépendance?

public static int ParseQueryInt(string key, int defaultValue) 
{ 
    NameValueCollection nvc; 
    if (HttpContext.Current.Request.QueryString["name"] != null) 
    { 
     //Parse strings. 
    } 
} 

EDIT: La solution de Akselson est le plus créatif et cette preuve de concept travaillé, à ma grande surprise, bien que j'ai aussi utilisé la solution de Skeet car il semble plus susceptibles de travailler dans toutes les situations.

public class Class1 
{ 
    [Test] 
    public void Test() 
    { 
     HttpContext.Current = new HttpContext(
new HttpRequest("test.aspx", "http://test.com/test.aspx", "querystring=value"), 
new HttpResponse(new StringWriter()) 
); 
     Assert.AreEqual(HttpContext.Current.Request.QueryString["querystring"], "value"); 
    } 
} 

Répondre

4

Vous pouvez définir HttpContext.Current à votre propre instance:

HttpContext.Current = new HttpContext(
    new HttpRequest("test.aspx","http://test.com/test.aspx","querystring=value"), 
    new HttpResponse(new StringWriter()) 
); 

Il pourrait être utile si vous ne voulez pas changer la méthode avant que vous l'avez testé.

7

Une option est introduire une autre surcharge:

public static int ParseQueryInt(string key, int defaultValue) 
{ 
    return ParseQuery(key, defaultValue, HttpContext.Current.Request); 
} 

public static int ParseQueryInt(string key, int defaultValue, 
           HttpRequest request) 
{ 
    NameValueCollection nvc; 
    if (request.QueryString["name"] != null) 
    { 
     //Parse strings. 
    } 
} 

Ensuite, vous réduisez votre « invérifiable » (ou du moins « difficile à tester ») le code à une simple redirection ... vous pouvez tester la diable hors de la version qui accepte une demande.

+0

Wau, c'était rapide! Et vous lisiez aussi mon esprit :) –

+6

Vous pourriez faire la deuxième surcharge interne et l'utiliser à partir de l'assemblage de test au moyen de l'attribut InternalsVisibleTo. Vous n'encombrez donc pas votre API à des fins de test unitaire. –

Questions connexes