Question

我正在开发一个Web API端点，它将接受多部分/混合消息作为POST。我面临的问题是如何在单元测试中模拟这样的请求？

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

我知道在测试中调用post之前，我必须创建请求对象并将测试条件置于其中以及控制器中。我在排序时遇到的问题是将多部分内容转换为ReadAsMultipartAsync()调用的正确形式的正确方法。

我将这个方法拼凑在一起，并且当它被输入上述控制器时，它所创建的请求被正确接受和解析。但是，设置断点并检查请求对象在通过此测试构建时与由fiddler之类的东西生成并通过管道进入时看起来非常不同。管道的内容类型为System.Web.Http.WebHost.HttpControllerHandler.LazyStreamContent，而测试调试为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;
}

我想我担心这种技术会导致错误的安全感，因为测试不会以与管道运行时相同的格式向控制器提供内容。有没有更好的方法来构建我的测试请求？或者我是否过于偏执，这对我的情景来说是一个可行的选择？

编辑：我们已经达到了尝试从外部代码测试此端点的程度，我们发现LazyStream和Multipart之间存在显着的性能差异。在提交与内部测试相同的数据时，外部代码通常会超时。

Answer 1

单元测试的目的是确保一旦收到数据，您的代码就会正常运行。假设您了解管道的工作原理，您可以放心地假设管道将正常工作。我将以您已经布局的方式继续进行单元测试，然后进行一些实时集成测试，以确保管道按预期工作。集成测试可以作为验证测试套件的一部分运行，不一定与每个构建一起运行，因为它只是确认您对管道功能的假设。

在单元测试中创建多个部分/混合表单请求

1 个答案: