Why would you write unit-tests for controllers?

Question

To me this is a totally irrelevant unit-test and I don't understand why someone would spent time writing it, since there is very little value to gain from it. I would know perfectly well if this controller returned the wanted type by executing the method in a browser. Really, do you believe a test is needed for this and why ?

public class ConstituencyControllerTests
{
    private ConstituencyController _constituencyController;
    private Mock<IConstituencyService> _IConstituencyServiceMock;

    public ConstituencyControllerTests() {
        _IConstituencyServiceMock = new Mock<IConstituencyService>();
    }

    [Test]
    public async Task I_Check_For_Return_Type_And_Result() {
        _constituencyController = new ConstituencyController( _IConstituencyServiceMock.Object );

        var result = await _constituencyController.Get();
        var content = ( (dynamic)result ).Content;

        Assert.IsEmpty( content );
        Assert.IsInstanceOf( typeof( System.Web.Http.Results.OkNegotiatedContentResult<IEnumerable<ListOfConstituencies>> ), result );
        _IConstituencyServiceMock.Verify( x => x.ListOfConstituencies(), Times.Once() );
    }
}

Answer 1

They key point is here:

I would know perfectly well if this controller returned the wanted type by executing the method in a browser

Unit testing is about automation of non-regression testing simple units of code, not that you look yourself. You don't want to do yourself always unit testing in your application.

EDIT : Adding @anotherdave comment :

It's about ease of scaling. Testing one controller in a browser may be OK; what about 10, 20, 50 controllers? You'll write the test once; you may need to update it when you change the controller, which is overhead. But how often do you deploy? Surely a manual check each time there is much more overhead than the test.

As an alternative to @Vladislav's answer, unit testing absolutely everything can be an overkill, and really undesirable. If you need something lighter you can do higher level non-regression testing using Selenium. Surely you'll get less coverage than unit-testing, but you can get a reasonable coverage which cost way less time doing unit-testing and is more flexible.

That is, if you unit-test everything you have to update one or more tests each time you modify a simple element.

Answer 2

Why would you write unit-tests for controllers?

Because without knowing the context you can't say for sure if you need to test this or that. Here are some reasons, why you might want to test controllers:

• controller may contain complex service wiring logic, which is error-prone. Services themselves might work fine it's the result you want to test and for some reason you considered not to introduce orchestration layer into your app
• your controllers contain THE WHOLE bussiness logic of the application and controllers are actually all you CAN test (please don't pretent that all your life you worked with ideal codebases, there ARE such codebases, believe me)
• your team consists of 99% geniuses and 1% of average people and you want to keep that 1% out of bugs in their salary

Answer 3

I completely agree with the OP.

A unit test for a controller is pointless. You test your controllers implicitly via regression tests (using Selenium for example).

You should TDD all the components/objects the controller uses and keep the controllers as thin as possible. Then everything is properly unit tested. What you want to be certain of is that everything works well together when performing web requests. That's regression testing.