Unit testing an HttpApplication

后端 未结 3 1939
天涯浪人
天涯浪人 2020-12-31 10:45

I have a class derived from HttpApplication that adds some extra features. I\'m to the point where I need to unit test these features, which means I have to be able to creat

相关标签:
3条回答
  • 2020-12-31 11:14

    I found the following blog earlier which explains quite a nice approach using Microsoft Moles.

    http://maraboustork.co.uk/index.php/2011/03/mocking-httpwebresponse-with-moles/

    In short the solution suggests the following:

        [TestMethod]
        [HostType("Moles")]
        [Description("Tests that the default scraper returns the correct result")]
        public void Scrape_KnownUrl_ReturnsExpectedValue()
        {
            var mockedWebResponse = new MHttpWebResponse();
    
            MHttpWebRequest.AllInstances.GetResponse = (x) =>
            {
                return mockedWebResponse;
            };
    
            mockedWebResponse.StatusCodeGet = () => { return HttpStatusCode.OK; };
            mockedWebResponse.ResponseUriGet = () => { return new Uri("http://www.google.co.uk/someRedirect.aspx"); };
            mockedWebResponse.ContentTypeGet = () => { return "testHttpResponse"; }; 
    
            var mockedResponse = "<html> \r\n" +
                                 "  <head></head> \r\n" +
                                 "  <body> \r\n" +
                                 "     <h1>Hello World</h1> \r\n" +
                                 "  </body> \r\n" +
                                 "</html>";
    
            var s = new MemoryStream();
            var sw = new StreamWriter(s);
    
                sw.Write(mockedResponse);
                sw.Flush();
    
                s.Seek(0, SeekOrigin.Begin);
    
            mockedWebResponse.GetResponseStream = () => s;
    
            var scraper = new DefaultScraper();
            var retVal = scraper.Scrape("http://www.google.co.uk");
    
            Assert.AreEqual(mockedResponse, retVal.Content, "Should have returned the test html response");
            Assert.AreEqual("http://www.google.co.uk/someRedirect.aspx", retVal.FinalUrl, "The finalUrl does not correctly represent the redirection that took place.");
        }
    
    0 讨论(0)
  • 2020-12-31 11:29

    Unfortunately, this isn't particularly easy to do, as the HttpApplication doesn't lend itself to mocking very easily; there is no interface to mock against and most of the methods aren't marked as virtual.

    I recently had a similar problem with HttpRequest and HttpWebResponse. In the end, the solution I went for was to create a straight "pass-through" wrapper for the methods I wanted to use:

    public class HttpWebRequestWrapper : IHttpWebRequestWrapper
        {
            private HttpWebRequest httpWebRequest;
    
            public HttpWebRequestWrapper(Uri url)
            {
                this.httpWebRequest = (HttpWebRequest)HttpWebRequest.Create(url);
            }
    
            public Stream GetRequestStream()
            {
                return this.httpWebRequest.GetRequestStream();
            }
    
            public IHttpWebResponseWrapper GetResponse()
            {
                return new HttpWebResponseWrapper(this.httpWebRequest.GetResponse());
            }
    
            public Int64 ContentLength
            {
                get { return this.httpWebRequest.ContentLength; }
                set { this.httpWebRequest.ContentLength = value; }
            }
    
            public string Method 
            {
                get { return this.httpWebRequest.Method; }
                set { this.httpWebRequest.Method = value; }
            }
    
            public string ContentType
            {
                get { return this.httpWebRequest.ContentType; }
                set { this.httpWebRequest.ContentType = value; }
            }
    }
    

    etc, etc

    This let me mock against my own wrapper interface. Not necessarily the most elegant thing in the world, but a very useful way of mocking out some of the less "mockable" parts of the framework.

    Before you rush off and do this though, it is worth reviewing what you've got and seeing if there is a better approach to your tests that would avoid you having to wrap classes.

    In the case of HttpWebRequest, HttpApplication et al, there often isn't IMHO.

    In order to set this wrapper in mock (using my HttpWebRequest example above) you then do stuff like this with Moq:

    var mockWebRequest = new Mock<IHttpWebRequestWrapper>();
    mockWebRequest.SetupSet<string>(c => c.Method = "POST").Verifiable();
    mockWebRequest.SetupSet<string>(c => c.ContentType = "application/x-www-form-urlencoded").Verifiable();
    mockWebRequest.SetupSet<int>(c => c.ContentLength = 0).Verifiable();
    
    0 讨论(0)
  • 2020-12-31 11:32

    IMHO adding a functionality by extending HttpApplication is not the best thing to do. It is so difficult to mock the HttpContext because of the private/internal/sealed classes that even if you succeed your unit tests will be so cluttered with mocking code that you will no longer be able to understand what you are actually testing.

    Could you give more details on what functionality you are adding? Maybe there's a better way of adding this functionality to your application.

    0 讨论(0)
提交回复
热议问题