¿Por qué escribirías pruebas unitarias para controladores?

Para mí, esta es una prueba de unidad totalmente irrelevante y no entiendo por qué alguien pasaría tiempo escribiéndola, ya que hay muy poco valor para obtenerla. Lo sabría perfectamente si este controlador devolviera el tipo deseado ejecutando el método en un navegador. Realmente, ¿crees que se necesita una prueba para esto y 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() );
    }
}

El punto clave está aquí:

Lo sabría perfectamente si este controlador devolviera el tipo deseado ejecutando el método en un navegador

La prueba unitaria se trata de la automatización de pruebas de no regresión de unidades simples de código, no de que usted mismo se vea. No desea hacer usted mismo siempre pruebas unitarias en su aplicación.

EDITAR: Agregar comentario @anotherdave:

Se trata de la facilidad de escalado. Probar un controlador en un navegador puede estar bien; ¿Qué pasa con 10, 20, 50 controladores? Escribirás la prueba una vez; Es posible que deba actualizarlo cuando cambie el controlador, que está sobrecargado. Pero, ¿con qué frecuencia se implementa? Seguramente una comprobación manual cada vez que hay mucho más gastos generales que la prueba

Como alternativa a la respuesta de @ Vladislav , la unidad que prueba absolutamente todo puede ser una exageración, y realmente indeseable. Si necesita algo más liviano, puede hacer pruebas de no regresión de mayor nivel utilizando Selenium. Seguramente obtendrá menos cobertura que las pruebas unitarias, pero puede obtener una cobertura razonable que cuesta mucho menos tiempo haciendo pruebas unitarias y es más flexible.

Es decir, si realiza una prueba unitaria de todo, debe actualizar una o más pruebas cada vez que modifique un elemento simple.

¿Por qué escribirías pruebas unitarias para controladores?

Porque sin conocer el contexto no puedes decir con certeza si necesitas probar esto o aquello. Aquí hay algunas razones por las que es posible que desee probar los controladores:

• El controlador puede contener una lógica de cableado de servicio compleja, que es propensa a errores. Los servicios en sí pueden funcionar bien, es el resultado que desea probar y, por alguna razón, consideró no introducir la capa de orquestación en su aplicación
• sus controladores contienen TODA la lógica de negocios de la aplicación y los controladores son en realidad todo lo que PUEDE probar (por favor, no pretenda que toda su vida trabajó con bases de códigos ideales, existen tales bases de códigos, créanme)
• su equipo está formado por el 99% de genios y el 1% de las personas promedio y desea mantener ese 1% fuera de los errores en su salario

Estoy completamente de acuerdo con el OP.

Una prueba unitaria para un controlador no tiene sentido. Usted prueba sus controladores implícitamente mediante pruebas de regresión (usando Selenium, por ejemplo).

Debe TDD todos los componentes / objetos que usa el controlador y mantener los controladores lo más delgados posible. Entonces todo se prueba adecuadamente en la unidad. De lo que quiere estar seguro es de que todo funciona bien cuando se realizan solicitudes web. Eso es prueba de regresión.