Can not understand how dependency injection can ease testing inside asp.net MVC

Question

Each time i read an article or a book about asp.net MVC , there will be a chapter for dependency injection and repository . now i can easily feel the benefits of using repository over hard coding the entity framework code inside the action methods, as using repository i can write the methods which uses the entity framework inside my repository methods and reuse these methods over my action method, so i can easily understand that using Repository will facilitate re-usability .

but when it comes to dependency injection, authors always say that it facilitate testing and unit testing. so they say instead of initiating the repository class inside the controller class i will be initiating an interface of the repository class. and they say this will facilitate the unit testing.. but i can not get my mind on this , mainly why imitating the repository interface inside my controller class will facilitate unit testing while initiating the repository class itself inside my controller class will not !!

can anyone adivce on this?

Answer 1

Consider a simple blog, and a PostsController that shows a blog post.

You enable dependency injection by setting the IPostRepository object using a constructor argument and instead of instantiating a concrete class in the controller:

public class PostsController : Controller
{
    private IPostRepository posts;

    public PostsController(IPostRepository posts)
    {
        if (posts == null)
            throw new ArgumentNullException("posts");

        this.posts = posts;
    }

    public ActionResult Details(int id)
    {
        BlogPost post = posts.Find(id);

        if (post == null)
            return HttpNotFound();

        BlogPostDetails model = new BlogPostDetails(post);

        return View(model);
    }
}

By allowing the posts repository to be injected, we can unit test the logic in the controller by providing a "mock" object. In this case, I'm using Moq, an object mocking library available on NuGet (not an endorsement, just for the sake of completing the example):

[TestClass]
public class BlogPostTests
{
    private IPostRepository mockRepository;

    [TestInitialize]
    public void Setup()
    {
        this.mockRepository = new Moq.Mock<IPostRepository>();
    }

    [TestMethod]
    public void ReturnsView()
    {
        var expectedPost = new BlogPost("Test Title", "<p>Body text</p>", DateTime.Parse("2017/01/13"));

        mockRepository.Setup(posts => posts.Find(1))
            .Returns(expectedPost) // posts.Find(1) will return a test stub
            .Verifiable(); // If posts.Find(1) doesn't get called, test fails

        var controller = new PostsController(mockRepository.Object);
        var result = controller.Details(1);

        // Assert that correct view was returned
    }
}

Now you can disconnect your controller from the rest of the technology stack and just test the "Details" method, making this a true Unit Test. As an added benefit, this test will execute in a millisecond or less. Compare that to a manual functional test run by a human, that will probably take upwards of a minute to set up the data and verify it, or 20-30 seconds for an automated functional test. The unit test will execute faster by an order of magnitude.

Answer 2

The point of unit testing is to isolate away any dependencies. Otherwise you are not unit testing, you are integration testing.

The problem

So how do you isolate away your dependencies so you are only testing the code of interest? Well let's take a look.

Consider the following example controller/action:

class MyController
{
    public ActionResult MyAction()
    {
        if (HttpContext.Current.Request.RawUrl.Contains("SomeString")
        {
            return Redirect("/Someurl");
        }
        return View();
    }
}

This is terrible code for a number of reasons (model binding, anyone?)... but for the present discussion, set that aside, and just note that HttpContext is created by the action method via a sort of singleton pattern. It's not injected, and there is no way to change it, other than to modify your code, or do something really weird with the .NET profiling API, like TypeMock does. Without heroic efforts, you are stuck using the real HttpContext object in the .NET runtime.

Now imagine you want to write a unit test to see if the action method does indeed perform a redirect when the URL contains "SomeString". how would you do it? Where do you get the HttpContext? You need a real one. So do you spin up a web server on your unit testing machine? Invoke it with a web client? Will you need to sign on? Create cookies? Ugh.

Bottom line: You have no way to isolate away the dependency on HttpContext.

A better way

If we were to modernize this with a bit of DI, it might look like this:

class MyController
{
    private readonly HttpContextBase _httpContext;

    public MyController(HttpContextBase context)  //Injected
    {
        _httpContext = context;
    }

    public ActionResult MyAction()
    {
        if (_httpContext.Request.RawUrl.Contains("SomeString")
        {
            return Redirect("/Someurl");
        }
        return View();
    }
}

Now we can test this, by supplying a mockup of the HTTP context that conforms to HttpContextBase's interface, like this:

class MockHttpRequest: System.Web.HttpRequestBase
{
    public override string RawUrl
    {
        get
        {
            return "SomeString";
        }
    }
}
class MockHttpContext : System.Web.HttpContextBase
{
    public override System.Web.HttpRequestBase Request
    {
        get
        {
            return new MockHttpRequest();
        }
    }
}

And in your unit test code:

//Arrange
var context = new MockHttpContext();
var controller = new MyController(context);

//Act
var result = controller.MyAction();

//Assert
Assert.IsTrue(result is RedirectResult);

Piece of cake. Don't need a web server. Don't even need Moq or TypeMock or Fakes. You can do it all yourself. It would not only be harder, but it would be impossible the traditional way, without a mocking framework.

P.S.

Incidentally, Microsoft thought this was so valuable they added HttpContextBase just so that it could be injected and overridden in unit tests (the regular HttpContext is sealed). If they went to the trouble to add it to the runtime, it's probably worth using.