How should one unit test a .NET MVC controller?

Question

I'm looking for advice regarding effective unit testing of .NET mvc controllers.

Where I work, many such tests use moq to mock the data layer and to assert that certain data-layer methods are called. This doesn't seem useful to me, since it essentially verifies that the implementation has not changed rather than testing the API.

I've also read articles recommending things like checking that the type of view model returned is correct. I can see that providing some value, but alone it doesn't seem to merit the effort of writing many lines of mocking code (our application's data model is very large and complex).

Can anyone suggest some better approaches to controller unit testing or explain why the above approaches are valid/useful?

Thanks!

Answer 1

You should first put your controllers on a diet. Then you can have fun unit testing them. If they are fat and you have stuffed all your business logic inside them, I agree that you will be passing your life mocking stuff around in your unit tests and complaining that this is a waste of time.

When you talk about complex logic, this doesn't necessarily mean that this logic cannot be separated in different layers and each method be unit tested in isolation.

Answer 2

Yes, you should test all the way to the DB. The time you put into mocking is less and the value you get from mocking is very less too(80% of likely errors in your system cannot be picked by mocking).

And this is a great article discussing the benefits of integration testing over unit testing because "unit testing kills!" (it says)

When you test all the way from a controller to DB or web service then it is not called unit testing but integration testing. I personally believe in integration testing as opposed to unit testing, even though they both serve different purposes.. even though we need both unit testing and integration testing. 'Time constraints' are real, so writing both will not be practical hence just stick to Integration Tests alone. And I am able to do test-driven development successfully with integration tests(scenario testing).

Here is how it works for our team. Every test class in the beginning regenerates DB and populates/seeds the tables with minimum set of data(eg: user roles). Based on a controllers need we populate DB and verify if the controller does it's task. This is designed in such a way that DB corrupt data left by other methods will never fail a test. Except time take to run, pretty much all qualities of unit test(even though it is a theory) are gettable. Time taken to sequentially run can be reduced with containers. Also with containers, we don't need to recreate DB as every test gets its own fresh DB in a container(which will be removed after the test).

There were only 2% situations(or very rarely) in my career when I was forced to use mocks/stubs as it was not possible to create a more realistic data source. But in all other situations integration tests was a possibility.

It took us time to reach a matured level with this approach. we have a nice framework which deals with test data population and retrieval(first class citizens). And it pays off big time! First step is to say goodbye to mocks and unit tests. If mocks do not make sense then they are not for you! Integration test gives you good sleep.

===================================

Edited after a comment below: Demo

Integration test or functional test has to deal with DB/source directly. No mocks. So these are the steps. You want to test getEmployee( emp_id). all these 5 steps below are done in a single test method.

1. Drop DB

2. Create DB and populate roles and other infra data

3. Create an employee record with ID

4. Use this ID and call getEmployee(emp_id)// this could an api-url call (that way db connection string need not be maintained in a test project, and we could test almost all environment by simply changing domain names)

5. Now Assert()/ Verify if the returned data is correct

   This proves that getEmployee() works . Steps until 3 requires you to have code used only by test project. Step 4 calls the application code. What I meant is creating an employee (step 2) should be done by test project code not application code. If there is an application code to create employee (eg: CreateEmployee()) then this should not be used. Same way, when we test CreateEmployee() then GetEmployee() application code should not be used. We should have a test project code for fetching data from a table.

This way there are no mocks! The reason to drop and create DB is to prevent DB from having corrupt data. With our approach, the test will pass no matter how many times we run it.

Special Tip: In step 5 getEmployee() returns an employee object. If later a developer removes or changes a field name the test breaks. What if a developer adds a new field later? And he/she forgets to add a test for it (assert)? Test would not pick it up. The solution is to add a field count check. eg: Employee object has 4 fields (First Name, Last Name, Designation, Sex). So Assert number of fields of employee object is 4. So when new field is added our test will fail because of the count and reminds the developer to add an assert field for the newly added field.

Answer 3

The point of a unit test is to test the behaviour of a method in isolation, based on a set of conditions. You set the conditions of the test using mocks, and assert the method's behaviour by checking how it interacts with other code around it -- by checking which external methods it tries to call, but particularly by checking the value it returns given the conditions.

So in the case of Controller methods, which return ActionResults, it is very useful to inspect the value of the returned ActionResult.

Have a look at the section 'Creating Unit Tests for Controllers' here for some very clear examples using Moq.

Here is a nice sample from that page which tests that an appropriate view is returned when the Controller attempts to create a contact record and it fails.

[TestMethod]
public void CreateInvalidContact()
{
    // Arrange
    var contact = new Contact();
    _service.Expect(s => s.CreateContact(contact)).Returns(false);
    var controller = new ContactController(_service.Object);

    // Act
    var result = (ViewResult)controller.Create(contact);

    // Assert
    Assert.AreEqual("Create", result.ViewName);
}

Answer 4

I don't see much point in unit testing the controller, since it is usually just a piece of code that connects other pieces. Unit testing it typically includes lots of mocking and just verifies that the other services are connected correctly. The test itself is a reflection of the implementing code.

I prefer integration tests -- I start not with a concrete controller, but with an Url, and verify that the returned Model has the correct values. With the help of Ivonna, the test might look like:

var response = new TestSession().Get("/Users/List");
Assert.IsInstanceOf<UserListModel>(response.Model);

var model = (UserListModel) response.Model;
Assert.AreEqual(1, model.Users.Count);

I can mock the database access, but I prefer a different approach: setup an in-memory instance of SQLite, and recreate it with each new test, together with the required data. It makes my tests fast enough, but instead of complicated mocking, I make them clear, e.g. just create and save a User instance, rather than mock the UserService (which might be an implementation detail).

Answer 5

Usually when you're talking about unit tests, you're testing one individual procedure or method, not an entire system, while trying to eliminate all external dependencies.

In other words, when testing the controller, you're writing tests method by method and you should not need to even have the view or model loaded, those are the parts you should "mock out". You can then change the mocks to return values or errors that are hard to reproduce in other testing.

Answer 6

I usually follow this guide for ASP.NET Core:

https://docs.microsoft.com/en-us/aspnet/core/mvc/controllers/testing?view=aspnetcore-5.0

Code samples:

https://github.com/dotnet/AspNetCore.Docs/tree/master/aspnetcore/mvc/controllers/testing/samples/

Example:

Controller:

public class HomeController : Controller
{
    private readonly IBrainstormSessionRepository _sessionRepository;

    public HomeController(IBrainstormSessionRepository sessionRepository)
    {
        _sessionRepository = sessionRepository;
    }

    public async Task<IActionResult> Index()
    {
        var sessionList = await _sessionRepository.ListAsync();

        var model = sessionList.Select(session => new StormSessionViewModel()
        {
            Id = session.Id,
            DateCreated = session.DateCreated,
            Name = session.Name,
            IdeaCount = session.Ideas.Count
        });

        return View(model);
    }

    public class NewSessionModel
    {
        [Required]
        public string SessionName { get; set; }
    }

    [HttpPost]
    public async Task<IActionResult> Index(NewSessionModel model)
    {
        if (!ModelState.IsValid)
        {
            return BadRequest(ModelState);
        }
        else
        {
            await _sessionRepository.AddAsync(new BrainstormSession()
            {
                DateCreated = DateTimeOffset.Now,
                Name = model.SessionName
            });
        }

        return RedirectToAction(actionName: nameof(Index));
    }
}

Unit test:

[Fact]
public async Task Index_ReturnsAViewResult_WithAListOfBrainstormSessions()
{
    // Arrange
    var mockRepo = new Mock<IBrainstormSessionRepository>();
    mockRepo.Setup(repo => repo.ListAsync())
        .ReturnsAsync(GetTestSessions());
    var controller = new HomeController(mockRepo.Object);

    // Act
    var result = await controller.Index();

    // Assert
    var viewResult = Assert.IsType<ViewResult>(result);
    var model = Assert.IsAssignableFrom<IEnumerable<StormSessionViewModel>>(
        viewResult.ViewData.Model);
    Assert.Equal(2, model.Count());
}