Is there a unit-testable way to upload files to AS

问题:

I'm working in a project that uses the new ASP.NET WebAPI. My current task is to accept an uploaded file. So far, I have used TDD to drive out the WebAPI code, but I've hit a wall with uploading. I'm currently following the advice found at http://www.asp.net/web-api/overview/working-with-http/sending-html-form-data,-part-2, but there seems to be no way at all to drive this out of a unit test. In order to get at the file and form data, I have to use MultipartFormDataStreamProvider, which is impossible to mock and/or override. Short of forsaking my TDD approach, what can I do?

Here's the code from the example:

public Task<HttpResponseMessage> PostFormData()
{
    // Check if the request contains multipart/form-data.
    if (!Request.Content.IsMimeMultipartContent())
    {
        throw new HttpResponseException(HttpStatusCode.UnsupportedMediaType);
    }

    string root = HttpContext.Current.Server.MapPath("~/App_Data");
    var provider = new MultipartFormDataStreamProvider(root);

    // Read the form data and return an async task.
    var task = Request.Content.ReadAsMultipartAsync(provider).
        ContinueWith<HttpResponseMessage>(t =>
        {
            if (t.IsFaulted || t.IsCanceled)
            {
                Request.CreateErrorResponse(HttpStatusCode.InternalServerError, t.Exception);
            }

            // This illustrates how to get the file names.
            foreach (MultipartFileData file in provider.FileData)
            {
                Trace.WriteLine(file.Headers.ContentDisposition.FileName);
                Trace.WriteLine("Server file path: " + file.LocalFileName);
            }
            return Request.CreateResponse(HttpStatusCode.OK);
        });

    return task;
}

The first problem is this line:

var provider = new MultipartFormDataStreamProvider(root);

For starters, to unit test this code, I need to be able to inject such a provider. It does WAY too much in that simple constructor call to be "newing it up" in line. There's got to be another way. (If not, WebAPI fails)

回答1:

I abstracted out a provider wrapper so I could mock those moving parts, something like

    public interface IMultiPartFormDataStreamProviderWrapper : IDependency
    {
        string LocalFileName { get; }
        MultipartFormDataStreamProvider Provider { get; }
    }

    public class MultiPartFormDataStreamProviderWrapper : IMultiPartFormDataStreamProviderWrapper
    {
        public const string UploadPath = "~/Media/Default/Vocabulary/";
        private MultipartFormDataStreamProvider provider;

        public MultiPartFormDataStreamProviderWrapper(IHttpContextAccessor httpContextAccessor)
        {
            provider = new CustomMultipartFormDataStreamProvider(httpContextAccessor.Current().Server.MapPath(UploadPath));
        }

        public string LocalFileName
        {
            get { return provider.FileData[0].LocalFileName; }
        }


        public MultipartFormDataStreamProvider Provider
        {
            get { return provider; }
        }
    }

So I could then do something like

    if (Request.Content.IsMimeMultipartContent())
    {
        return Request.Content.ReadAsMultipartAsync(provider.Provider).ContinueWith(t => 
                    {
                        if (t.IsCanceled || t.IsFaulted)
                            return (object)new { success = false };

Not ideal, but gives some piece of mind. What do you think?

回答2:

If you use the self-hosting capability, you can write a unit test that:

• Starts up the controllers (and various other formatters/filters/etc.)
• Uses an HttpClient (or personally, I would use RestSharp) to submit a file to that controller (with RestSharp, you can use the AddFile function to do this)
• Validates the input stream however you would like (e.g. by overriding the provider or just inspecting the value that is passed to a test controller or something)

回答3:

If you haven't thrown in the towel on Web API yet, you might try System.Net.Http.TestableMultipartStreamProviders, which are a drop-in rewrite of the Microsoft stream providers. Their benefit is that they rely on SystemWrapper for file operations, which means the file operations can be mocked in unit tests. The wiki gives some ideas about leveraging DI to make testing controllers less of a pain.

回答4:

The answer is "no". ASP.NET is an inheritance-based framework. If you're trying to write composition-based applications, you will, at some point, find friction and road-blocks. Time to switch to something like Nancy.