私は、マルチパート/混合メッセージをPOSTとして受け付けるWeb APIエンドポイントで作業しています。私が直面している問題は、単体テストでそのような要求を模擬する方法です。ユニットテストでのmulitpart/mixedフォーム要求の作成
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...
}
私は、私がリクエストオブジェクトを作成し、そこに私の試験条件をシードする必要があることを知っていると、コントローラ私のテストでポストを呼び出す前に。並べ替えに問題があるのは、マルチパートのコンテンツをReadAsMultipartAsync()呼び出しの正しい形式にする正しい方法です。
私はこのメソッドをまとめました。作成したリクエストは、上記のコントローラに入力されると正しく受け入れられ、解析されます。しかし、このテストでビルドされたときと、パイプラインを通して入ってくるようなものによって生成されたときに、ブレークポイントを設定してリクエストオブジェクトを検査することは、非常に異なっています。テストのデバッグがSystem.Net.Http.MultipartContentである間、パイプラインのタイプはSystem.Web.Http.WebHost.HttpControllerHandler.LazyStreamContentです。
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;
}
私はこれがライブ行くだろうと、テストがパイプラインと同じ形式でコントローラに物事を供給されていないため、この技術は、誤った安心感につながることを心配していますね。私のテストのリクエストを作成する良い方法はありますか？あるいは、私は過度に妄想的であり、これは私のシナリオにとって実行可能な選択肢ですか？
EDIT： 外部コードからこのエンドポイントをテストしようとしており、LazyStreamとMultipartのパフォーマンスに大きな違いが見られました。外部コードは通常、内部テストと同じデータを送信するときにタイムアウトになります。