Por que você escreveria testes de unidade para controladores?

Para mim, este é um teste unitário totalmente irrelevante e não entendo por que alguém passaria algum tempo escrevendo, pois há muito pouco valor a ganhar com isso. Eu saberia perfeitamente bem se esse controlador retornasse o tipo desejado executando o método em um navegador. Realmente, você acredita que é necessário um teste para isso e por quê?

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() );
    }
}

O ponto principal é aqui:

Eu saberia perfeitamente bem se esse controlador retornasse o tipo desejado executando o método em um navegador

A testagem unitária é sobre a automação de unidades de código simples de teste sem regressão, não que você se veja. Você não quer fazer você mesmo sempre testando a unidade em seu aplicativo.

EDIT: Adicionando comentário @anotherdave:

É sobre a facilidade de dimensionamento. Testar um controlador em um navegador pode estar OK; que tal 10, 20, 50 controladores? Você escreverá o teste uma vez; pode ser necessário atualizá-lo quando você altera o controlador, que está sobrecarregado. Mas com que frequência você implanta? Certamente, uma verificação manual sempre que houver muito mais sobrecarga que o teste

Como alternativa à resposta de @ Vladislav , o teste de unidade absolutamente tudo pode ser um exagero e realmente indesejável. Se você precisar de algo mais leve, poderá fazer testes de não regressão de nível superior usando o Selenium. Certamente, você terá menos cobertura do que o teste de unidade, mas poderá obter uma cobertura razoável, que custará muito menos tempo fazendo testes de unidade e é mais flexível.

Ou seja, se você fizer o teste unitário de tudo, precisará atualizar um ou mais testes sempre que modificar um elemento simples.

Por que você escreveria testes de unidade para controladores?

Porque sem conhecer o contexto, você não pode dizer com certeza se precisa testar isso ou aquilo. Aqui estão alguns motivos pelos quais você pode querer testar controladores:

• O controlador pode conter lógica de fiação de serviço complexa, que é propensa a erros. Os serviços em si podem funcionar bem. É o resultado que você deseja testar e, por algum motivo, considerou não introduzir a camada de orquestração no aplicativo.
• seus controladores contêm TODA a lógica comercial do aplicativo e os controladores são tudo o que você PODE testar (por favor, não pretenda que toda a sua vida você trabalhou com bases de código ideais, existem essas bases de código, acredite em mim)
• sua equipe é composta por 99% de gênios e 1% da média de pessoas e você deseja manter esse 1% de erros no salário

Concordo plenamente com o OP.

Um teste de unidade para um controlador é inútil. Você testa seus controladores implicitamente através de testes de regressão (usando Selenium, por exemplo).

Você deve TDD todos os componentes / objetos que o controlador usa e manter os controladores o mais fino possível. Então tudo é testado adequadamente. O que você quer ter certeza é que tudo funciona bem ao executar solicitações da Web. Isso é teste de regressão.