Perché dovresti scrivere unit test per i controller?

Question

Perché dovresti scrivere unit test per i controller?

#1 da (29 voti)
#2 da (23 voti)
#3 da (0 voti)

21

Per me questo è un test unitario totalmente irrilevante e non capisco perché qualcuno ci abbia dedicato del tempo a scriverlo, dal momento che il valore da ottenere è molto scarso. Saprei perfettamente se questo controller ha restituito il tipo desiderato eseguendo il metodo in un browser. Davvero, credi 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() );
    }
}

unit-testing

posta frostings 19.12.2016 - 12:43

fonte

3 risposte

Leggi altre domande sui tag unit-testing

Linguaggi di programmazione con un meccanismo di estensione della sintassi simile a Lisp [chiuso] Uscire da una piccola start-up in cui sei uno sviluppatore principale? [chiuso]

score 29 · Answer 1

Il loro punto chiave è qui:

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

L'analisi delle unità riguarda l'automazione dei test di non regressione semplici unità di codice, non il fatto che tu guardi te stesso. Non vuoi fare sempre te stesso test delle unità nella tua applicazione.

EDIT: aggiunta del commento @anotherdave:

Riguarda la facilità di ridimensionamento. Testare un controller in un browser può essere OK; Che ne dici di 10, 20, 50 controller? Scrivi il test una volta; potrebbe essere necessario aggiornarlo quando si modifica il controller, che è sovraccarico. Ma quanto spesso dispieghi? Sicuramente un controllo manuale ogni volta che c'è molto più sovraccarico del test

In alternativa alla risposta di @ Vladislav , l'unità di test assolutamente tutto può essere eccessivo e davvero indesiderabile. Se hai bisogno di qualcosa di più leggero puoi fare test di non regressione di livello più alto usando il selenio. Sicuramente avrai una copertura minore rispetto ai test unitari, ma puoi ottenere una copertura ragionabile che costa molto meno tempo eseguendo test unitari ed è più flessibile.

Cioè, se esegui un test unitario su tutto, devi aggiornare uno o più test ogni volta che modifichi un elemento semplice.

score 23 · Answer 2

Why would you write unit-tests for controllers?

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

il controller può contenere una complessa logica di cablaggio del servizio, che è soggetta a errori. I servizi stessi potrebbero funzionare bene è il risultato che vuoi 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 quello che puoi testare (per favore non pretendere che tutta la tua vita abbia lavorato con codebase ideali, ci sono tali codebases, credimi)
la tua squadra è composta al 99% da geni e all'1% della media delle persone e vuoi mantenere quell'1% di bug nel loro stipendio

score 0 · Answer 3

Sono completamente d'accordo con l'OP.

Un test unitario per un controller è inutile. Testate in modo implicito i vostri controllori tramite test di regressione (usando Selenium ad esempio).

Devi usare TDD tutti i componenti / oggetti che il controller usa e mantenere i controller il più sottili possibile. Quindi tutto è correttamente testato. Quello di cui si vuole essere certi è che tutto funzioni bene insieme quando si eseguono richieste web. Questo è il test di regressione.