Komponententest für eine Web-API-Methode ohne jegliche injizierte Abhängigkeit

Question

Ich habe eine Methode in meinem Web-API-Projekt und da es ziemlich einfach ist und es keine injizierte Abhängigkeit gibt und es sich um ein konkretes POSTed-Objekt handelt, bin ich nicht sicher, wie ich könnte einen Komponententest dafür erstellen. Gibt es etwas in der Gestaltung des folgenden Codes, den ich ändern könnte, um es testfreundlicher zu machen?

public class HomeController : ApiController 
{ 
    public HttpResponseMessage Post(RootObject root) 
    { 
     HttpResponseMessage httpResponse; 

     return TryCreateResponse(root, out httpResponse) ? httpResponse : Request.CreateErrorResponse(HttpStatusCode.InternalServerError, "An unhandled exception occurred on the server."); 
    } 

    private bool TryCreateResponse(RootObject root, out HttpResponseMessage httpResponse) 
    { 
     var success = false; 
     httpResponse = null; 
     try 
     { 
      var creator = (ModelState.IsValid)? 
       new OkResponseCreator(root) as IHttpResponseCreator: 
       new BadReqeuestResponseCreator(ApplicationSettings.HttpBadRequestErrorMessage); 

      var abstractHttpResponse = new ResponseContext(creator).CreateHttpResponse(); 
      httpResponse = Request.CreateResponse(abstractHttpResponse.StatusCode, abstractHttpResponse); 

      success = true; 
     } 
     catch 
     { 
      success = false; 
     } 

     return success; 
    } 
} 

Answer 1

Starten von HomeController.Post mit einer gefälschten RootObject testen und Ihr erwarteten Ergebnis Behauptung mit dem, was tatsächlich aus dem Test zurück.

Obwohl es keine Abhängigkeiten injizierten, wobei das Verfahren und durch die Erweiterung der Klasse abhängig von OkResponseCreator, BadReqeuestResponseCreatorResponseContext und ApplicationSettings.

Angesichts der Tatsache, dass das Ausmaß der Kopplung dieser Klassen in Ihrem Beispiel nicht völlig offensichtlich ist und auch, was ihre Abhängigkeiten sind, würde ich vorschlagen, dass Sie beginnen, indem Sie diese Klassen betrachten.

Wenn Ihr erster Test fehlschlägt, können Sie einen Zyklus von Refactoring und erneuten Tests versuchen, während Sie die genannten Klassen ansprechend darstellen, damit sie für eine bessere Testbarkeit sicher in den Controller injiziert werden können.