Devo testare i miei controller (MVC)?

Question

Utilizzo TDD da diversi mesi, ora mi piacerebbe imparare come testare i miei controller (MVC).

I test delle unità vengono eseguiti testando l'unità più piccola di ciascuna funzionalità. A volte, i controller non sono piccoli. Raccolgono dati da Modelli e passano poi alle viste.

Come si esegue il test dell'unità su un controller? Devo prendere in giro le dipendenze del controller?

I test del controller sono considerati test di integrazione?

Grazie.

Answer 1

La stessa domanda fatta ieri:

Does it make sense to test controllers

E a mio parere - Sì, ha senso per testare i controllori. È possibile:

• servizi finte dietro di loro, così è più facile per testare solo controller si
• servizi congedo unmocked e fare test di integrazione, nonché

Answer 2

che sto facendo TDD per molto tempo . Sto facendo TDD con ASP.NET MVC per più di un anno.

Ho iniziato con regole canoniche: "nessuna riga di codice senza test di unità", quindi ho testato tutto, inclusi i controller. I controllori devono essere testati, questo era uno degli obiettivi del framework MVC - Rendere tali elementi testabili.

Per le applicazioni di piccole dimensioni che si avvicinano funziona davvero bene. Quasi tutta la logica è inserita nel controller, tutto molto ben testato.

Ma finché ho continuato con MVC ho iniziato a cambiare idea. Cerco di mantenere i controller il più sottili possibile. Idealmente niente più come delegare la chiamata a qualche oggetto aziendale e avvolgere i risultati. Il resto è con i filtri.

Questo ha funzionato bene anche per me! Ora ho oggetti business implementati/testati separatamente, quindi il controller è solo un punto di integrazione. Nessun motivo per testare il punto di integrazione poiché è troppo piccolo.

Per quanto riguarda i test di integrazione: non ho ancora soddisfatto la situazione, dove effettivamente ne ho bisogno. Non dimenticare che i controllori dipendono sempre dalle astrazioni che vengono iniettate dal costruttore. Finché hai "buone" ipotesi su come funzionano queste astrazioni, crei i test unitari appropriati. Come hai fallito, hai appena corretto i test unitari.

I test di integrazione sono importanti e utili, ma cerco di crearli il meno possibile.

Answer 3

Prendo lo stesso approccio per i controller come Alexander B. I miei controller sono muti e stupidi. Tuttavia continuo a scrivere test per assicurarsi che chiamino correttamente gli oggetti business o service e che passino i parametri corretti.

Questo è probabilmente meglio illustrato da un bug reale che ho finalmente catturato la scorsa settimana. Ho un controller che consente ai manager di approvare o rifiutare le richieste degli utenti, ha due viste, una lista di richieste in sospeso e una vista dettagliata per ogni richiesta. Entrambe le viste possono approvare o negare. Il servizio a cui il controller chiama ha un sacco di altri metodi esposti, incluso uno per modificare lo stato delle richieste ...puoi vedere dove sta andando. La visualizzazione elenco ha definito il metodo corretto per approvare o negare e attivare il flusso di lavoro, la visualizzazione dettagli ha chiamato solo il metodo dello stato delle modifiche e non ha dato il via ad alcun ulteriore flusso di lavoro. Questo è stato il mio errore di codifica, ma per la vita di me non riuscivo a vederlo per anni: il flusso di lavoro scorreva in thread in background e ho passato una settimana a scorrere attraverso quei thread, supponendo che si trattasse di un errore in quella sezione.

Quindi per me

• Non appena il controller passa i dati altrove ha bisogno di prove.
• Se i controlli del controller modello validità ha bisogno di test (che cosa se qualcuno ha rimosso il controllo?)

ecc

Answer 4

Per sviluppare un test unità per il controller, il modo naturale è quello di prendi in giro le interfacce da cui dipende il controller (le "cose" che controlla, chiamiamole IControllable s). Quindi è possibile verificare che il controllore manipoli gli oggetti controllati nel modo previsto.

Se l'interazione tra il controllore e gli oggetti controllati è complicata, i test di integrazione dedicati possono avere senso. Ad esempio, potrebbero esserci una serie di classi che implementano IControllable - ognuna di queste implementazioni funzionerà bene insieme al controller? Forse più diversi IControllables interagiranno (utilizzare la stessa risorsa)? O il IControllables potrebbe avere dei modi complicati per configurarli che influenzano il loro comportamento? Un modo per testare questo è scrivere una suite di test riutilizzabile in cui si pompano in una serie di sospette implementazioni o combinazioni di IControllable.

Ultimo ma non meno importante, TDD è circa test di accettazione pure. Pertanto, quando si esegue TDD, si avrà anche un test end-to-end di alto livello per l'esecuzione di scenari che un utente finale riconoscerebbe. Molto probabilmente, anche questi eserciteranno il controller, verificando anche la corretta integrazione tra il controller e (alcune) classi.