As far as possible from the reliance on HttpContext

Source: Internet
Author: User
Tags abstract http request httpcontext stub

Today we mainly talk about the HttpContext of the problem of dependence.

The natural enemy of unit testing in is HttpContext, which is the core of, extremely complex, but unable to Mock1-it's hard to see how Microsoft can write such a large framework. Now this situation has improved a lot, so you can already use System.Web.Abstractions.dll, this assembly provides the abstraction for HttpContext, that is HttpContextBase abstract class. So in mvc, the various components are dependent on the httpcontextbase rather than the HttpContext. This is a good practice, everyone can get rid of HttpContext as far as possible.

But this seems to be a paradox. While HttpContext can already be mocks (this enhances testability), over-reliance on HttpContext is also an injury to unit testing. This is due to the nature of the HttpContext object: it is too complicated. You should have noticed that this is a collection of thousands of pet objects, from the request, reply, application, cache ... Contains almost all the information the Web application needs. If you are testing a method that relies on HttpContext, you will have to populate all kinds of information for HttpContext mock objects-depending on your business. Also, mocks are concerned with "behavior," meaning that it focuses on the "path" used to do something. So what if you could do one thing with multiple paths? Do you need to have all the paths ready before the test, and verify that the code being tested is "adopted and takes only one of the paths"? Therefore, the stub slowly into people's view. Stub is concerned with "state" ... This is another topic, it will also involve the use of record & Replay or Arrange-act-assert way to do unit testing, not to mention.

When it comes to unit testing of views, Lao Zhao used to talk about using only the data in ViewData in a view. This is not the first time to say that we have to give up HttpContext, since the "abstract" of this beneficial weapon, all "disharmony" factors can be separated. Imagine in the MVP mode, view and presenter use their own abstraction to interact, all Web controls, HttpContext and other objects are no longer exist, we see only "data" and "model." Also, in the MVC action method, HttpContext should not be used, which is based on good "testability" considerations. You might think that the HttpContextBase object is now ready to mock. Yes, it does, but doing so will cause the expansion of the unit test code because a considerable portion of the test code must focus on the preparation of the test data, not on the functionality being tested. For an action approach, it should focus on the interaction of the user with the business logic, rather than "how to convert an HTTP request into usable data." In the final analysis, we still have to "separate the attention point".

In MVC is responsible for the "transformation of data" level for model Binder. In this regard, the existing "examples" are mostly concerned with converting data in form or querystring into action parameters, although model binder is more available. For example, in the code for best practices, the original AccountController Delete method is implemented as follows:

Public ActionResult Delete (string userName)
.  MiddleTier.UserManager.Delete (userName);

Uri Urlreferrer = this.  Request.urlreferrer;
return this. Redirect (Urlreferrer.tostring ());

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.