Perché dovresti scrivere unit test per controller?

Per me questo è un test unitario del tutto irrilevante e non capisco perché qualcuno avrebbe trascorso del tempo a scriverlo, poiché c'è poco valore da guadagnare da esso. Saprei perfettamente se questo controller restituisse il tipo desiderato eseguendo il metodo in un browser. Credi davvero che sia necessario un test per questo e perché?

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

Il punto chiave è qui:

Saprei perfettamente se questo controller restituisse il tipo desiderato eseguendo il metodo in un browser

Unit-tesing riguarda l' automazione del test di non regressione semplici unità di codice, non che tu sembri. Non vuoi fare te stesso sempre unità nella tua applicazione.

EDIT: Aggiunta del commento @anotherdave:

Si tratta di facilità di ridimensionamento. Il test di un controller in un browser potrebbe essere OK; che dire di 10, 20, 50 controller? Scriverai il test una volta; potrebbe essere necessario aggiornarlo quando si cambia il controller, che è sovraccarico. Ma quanto spesso ti dispieghi? Sicuramente un controllo manuale ogni volta che c'è molto più sovraccarico del test

In alternativa a risposta @ Vladislav , test di unità assolutamente tutto può essere eccessivo e davvero indesiderabile. Se hai bisogno di qualcosa di più leggero, puoi fare test di non regressione di livello superiore usando Selenium. Sicuramente avrai meno copertura dei test unitari, ma puoi ottenere una copertura irrinunciabile che costa molto meno tempo a fare test unitari ed è più flessibile.

Cioè, se testate tutto ciò che dovete aggiornare uno o più test ogni volta che modificate un semplice elemento.

Perché dovresti scrivere unit test per controller?

Perché senza conoscere il contesto non si può dire con certezza se è necessario testare questo o quello. Ecco alcuni motivi per cui potresti voler testare i controller:

• il controller può contenere una logica di cablaggio di servizio complessa, soggetta a errori. I servizi stessi potrebbero funzionare correttamente è il risultato che si desidera testare e per qualche motivo hai considerato di non introdurre il livello di orchestrazione nella tua app
• i tuoi controller contengono TUTTA la logica di bussiness dell'applicazione e i controller sono in realtà tutto ciò che PUOI testare (per favore non pretendere che tutta la tua vita hai lavorato con basi di codice ideali, ci sono tali basi di codice, credimi)
• la tua squadra è composta per il 99% da geni e dall'1% di persone medie e tu vuoi mantenere quell'1% di bug nel loro stipendio

Sono completamente d'accordo con l'OP.

Un test unitario per un controller è inutile. Collaudi implicitamente i tuoi controller tramite test di regressione (usando Selenium per esempio).

È necessario TDD tutti i componenti / oggetti utilizzati dal controller e mantenere i controller il più sottili possibile. Quindi tutto è correttamente testato dall'unità. Quello di cui vuoi essere certo è che tutto funziona bene insieme quando si eseguono richieste Web. Questo è il test di regressione.