As far as possible from the reliance on HttpContext

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

The natural enemy of unit testing in ASP.net is HttpContext, which is the core of ASP.net, extremely complex, but unable to Mock¹-it's hard to see how Microsoft can write such a large asp.net 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 asp.net 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 ASP.net 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 asp.net 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)
{this
.　　MiddleTier.UserManager.Delete (userName);

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