Erstellen einer Multitpart-/Mischformularanforderung im Komponententest

Question

Ich arbeite an einem Web-API-Endpunkt, der mehrteilige/gemischte Nachrichten als POST akzeptiert. Das Problem, mit dem ich konfrontiert bin, ist, wie man eine solche Anfrage in einem Unit-Test nachbildet?

Der Kern der API-Methode ist:

public HttpResponseMessage Post(){ 
    var parsedContent=Request.Content.ReadAsMultipartAsync().Result; 
    foreach(var item in parsedContent.Contents) { 
     switch(item.Headers.ContentType.MediaType){ 
      case "application/json": 
       doSomething(item); 
       break; 
      case "text/plain": 
       doSomethingElse(item); 
       break; 
      case "application/pdf": 
       doAnotherThing(item); 
       break; 
      case "image/png": 
       doYetAnotherThing(item); 
       break; 
     } 
    } 
    //return status message based on results of previous calls... 
} 

Ich weiß, dass ich das Request-Objekt erstellen und meine Testbedingung hinein, und die Steuerung Saatgut, bevor Post in meinem Test-Aufruf. Was ich aussortieren kann, ist der richtige Weg, um den mehrteiligen Inhalt in die richtige Form für den ReadAsMultipartAsync() Aufruf zu bekommen.

Ich habe diese Methode zusammengefügt, und die Anforderung, die sie erstellt, wird korrekt akzeptiert und analysiert, wenn sie in den obigen Controller eingegeben wird. Das Festlegen eines Haltepunkts und das Überprüfen des Anforderungsobjekts sieht jedoch sehr unterschiedlich aus, wenn es von diesem Test erstellt wird, im Gegensatz zu etwas, das von etwas wie fiddler erzeugt wird und durch die Pipeline hereinkommt. Die Pipeline hat Inhalt vom Typ System.Web.Http.WebHost.HttpControllerHandler.LazyStreamContent, während das Test-Debug System.Net.Http.MultipartContent ist.

public static HttpRequestMessage CreateMixedPostRequest(string url, IEnumerable<HttpContent> contentItems) { 
    var request=new HttpRequestMessage(HttpMethod.Post, url); 
    var content=new MultipartContent("mixed"); 
    foreach(var item in contentItems) { 
     content.Add(item); 
    } 
    request.Content=content; 
    return request; 
} 

Ich glaube, ich mache mir Sorgen, dass diese Technik zu einem falschen Gefühl der Sicherheit führen wird, da der Test ist nicht die Dinge an die Steuerung im gleichen Format wie die Pipeline-Fütterung wird, wenn diese live geht. Gibt es eine bessere Möglichkeit, die Anfragen für meine Tests zu erstellen? Oder bin ich zu paranoid, und das ist eine brauchbare Option für mein Szenario?

EDIT: Wir haben den Punkt erreicht, wo wir versuchen, diesen Endpunkt von externem Code zu testen, und wir sehen erhebliche Leistungsunterschiede zwischen LazyStream und Multipart. Der externe Code erhält häufig Timeouts, wenn dieselben Daten wie die internen Tests gesendet werden.

Answer 1

Der Zweck eines Komponententests besteht darin, sicherzustellen, dass sich der Code nach dem Empfang der Daten korrekt verhält. Sie können davon ausgehen, dass die Pipe korrekt funktioniert, vorausgesetzt, Sie verstehen, wie die Pipeline funktioniert. Ich würde Ihre Komponententests in der von Ihnen festgelegten Weise fortsetzen und anschließend einige Live-Integrationstests durchführen, um sicherzustellen, dass die Pipeline wie erwartet funktioniert. Die Integrationstests können als Teil einer Verifikationstestsuite ausgeführt werden, die nicht unbedingt mit jedem Build ausgeführt wird, da dies lediglich eine Bestätigung Ihrer Annahmen über die Funktionalität der Pipeline darstellt.