2015-11-10 36 views
6

Pracuję nad punktem końcowym Web API, który będzie akceptował komunikaty wieloczęściowe/mieszane jako POST. Kwestią, przed którą stoję, jest to, jak wykpić taki wniosek w teście jednostkowym?Tworzenie żądania mulitpart/formularza mieszanego w teście jednostkowym

Istotą metody API:

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... 
} 

wiem, że mam do utworzenia obiektu żądania i nasion moje warunki testowe do niego, a kontroler, przed wywołaniem posta w moim teście. To, co mam problemy z posortowaniem, jest poprawnym sposobem, aby uzyskać treść wieloczęściową we właściwej formie dla wywołania ReadAsMultipartAsync().

Poskładałem tę metodę razem, a jej żądanie zostało zaakceptowane i poprawnie przetworzone podczas podawania do powyższego kontrolera. Jednak ustawienie punktu przerwania i inspekcja obiektu żądania wygląda zupełnie inaczej, gdy jest tworzony przez ten test, a generowany przez coś takiego jak skrzypek i wchodzący przez potok. Rurociąg ma zawartość typu System.Web.Http.WebHost.HttpControllerHandler.LazyStreamContent, podczas gdy testowe debugowanie to System.Net.Http.MultipartContent.

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; 
} 

Chyba martwię się, że technika ta będzie prowadzić do fałszywego poczucia bezpieczeństwa, ponieważ test nie jest karmienie rzeczy do sterownika w tym samym formacie jak rurociąg, gdy ten idzie na żywo. Czy istnieje lepszy sposób budowania próśb o moje testy? Czy jestem nadmiernie paranoidalny i jest to realna opcja dla mojego scenariusza?

EDYTOWANIE: Osiągnęliśmy punkt, w którym próbujemy przetestować ten punkt końcowy na podstawie kodu zewnętrznego i widzimy znaczące różnice w wydajności między LazyStream i Multipart. Kod zewnętrzny zwykle otrzymuje limity czasu przy przesyłaniu tych samych danych, co testy wewnętrzne.

Odpowiedz

1

Celem testu jednostkowego jest upewnienie się, że po otrzymaniu danych kod zachowuje się poprawnie. Możesz bezpiecznie założyć, że rura będzie działać poprawnie, zakładając, że rozumiesz, jak działa potok. Kontynuowałbym testy jednostkowe w taki sposób, jaki zaplanowałeś, a następnie sprawdzałeś niektóre testy na żywo, aby upewnić się, że potok działa zgodnie z oczekiwaniami. Testy integracyjne mogą być uruchamiane jako część zestawu testów weryfikacyjnych, który niekoniecznie jest uruchamiany z każdą kompilacją, ponieważ jest to po prostu potwierdzenie założeń dotyczących funkcjonalności potoku.