Perché i test MVC Views sono disapprovati?

23

Attualmente sto preparando le basi per un'applicazione ASP.Net MVC e sto esaminando quale tipo di unit test dovrei essere pronto a scrivere. Ho visto in più punti la gente essenzialmente dicendo "non preoccuparti di testare le tue opinioni, non c'è logica ed è banale e sarà coperto da un test di integrazione".

Non capisco come questa sia diventata la saggezza accettata. I test di integrazione hanno uno scopo completamente diverso rispetto ai test unitari. Se rompo qualcosa, non voglio sapere mezz'ora dopo quando i miei test di integrazione si interrompono, voglio sapere immediatamente.

Scenario di esempio: supponiamo di avere a che fare con un'app CRUD standard con un'entità cliente. Il cliente ha un nome e un indirizzo. A ogni livello di test, desidero verificare che la logica di recupero del cliente ottenga correttamente il nome e l'indirizzo.

Per testare l'unità sul repository, scrivo un test di integrazione per colpire il database. Per testare le regole aziendali, derido il repository, fornisco i dati appropriati delle regole aziendali e verifico che i risultati previsti vengano restituiti.

Cosa mi piacerebbe fare: per testare l'unità dell'interfaccia utente, derido le regole aziendali, configuro l'istanza del cliente prevista, eseguo il rendering della vista e verifico che la vista contenga i valori appropriati per l'istanza specificata.

Cosa sono bloccato a fare: Per testare l'unità nel repository, scrivo un test di integrazione, configuro un login appropriato, creo i dati richiesti nel database, apro un browser, navigo verso il cliente e verifico che la pagina risultante contenga la valori per l'istanza che ho specificato.

Mi rendo conto che c'è una sovrapposizione tra i due scenari discussi sopra, ma la differenza fondamentale è il tempo e lo sforzo necessari per impostare ed eseguire i test.

Se io (o un altro sviluppatore) rimuovo il campo dell'indirizzo dalla vista, non voglio aspettare che il test di integrazione lo scopra. Voglio essere scoperto e contrassegnato in un unit test che viene eseguito più volte al giorno.

Ho la sensazione che non stia solo afferrando qualche concetto chiave. Qualcuno può spiegare perché volere un riscontro immediato del test sulla validità di una vista MVC è una cosa negativa? (o, se non male, non è il modo previsto per ottenere un feedback)

unit-testing asp.net-mvc

— Peter Bernier
fonte

1

"To unit-test the repository, I write an integration test"Aspetta cosa? Questo non è un test unitario del repository. Stai automatizzando il test, ma il codice sotto test include ancora il DAL e il database. Per testare l'unità il repository è necessario isolarlo come per le regole aziendali.

— StuperUser

L'unità di test della vista resa come previsto è solo un test di unità che funziona il tuo motore di template. È come se il test unitario della C compilata contenga determinati blocchi di codice macchina, mentre l'unità sta testando il compilatore e non il codice.

— Raynos,

2

@Raynos Rispettosamente, non dovrò essere d'accordo. Se io (o un altro sviluppatore) collego erroneamente l'interfaccia utente per eseguire il rendering di un attributo di dati nel campo dell'interfaccia utente per un altro (ad esempio, "Nome" nel "Campo cognome", ciò non ha nulla a che fare con il motore di template, né è un problema DAL o BR .. è chiaramente un problema che verrebbe esposto solo alla vista

— Peter Bernier,

1

@PeterBernier hai un buon punto, ma trovo difficile definire la linea tra "test se il compilatore funziona" e "test se il mio codice funziona". Per non parlare del fatto che i test per l'interfaccia utente sono strettamente associati all'interfaccia utente. Qualsiasi modifica all'interfaccia utente causa il fallimento dei test. Non puoi davvero fare alcun tipo di refactoring dell'interfaccia utente senza far fallire un test.

— Raynos,

9

Il semplice test dell'interfaccia utente è abbastanza semplice in ASP.NET MVC. In sostanza, tutto ciò che devi fare è affermare che l'HTML restituito contiene gli elementi di cui hai bisogno. Sebbene ciò assicuri che la pagina HTML sia strutturata nel modo previsto, non verifica completamente l'interfaccia utente.

Il corretto test dell'interfaccia utente Web richiede uno strumento come Selenium che utilizzerà i browser sul tuo computer e assicuri che JavaScript e HTML funzionino correttamente in tutti i browser. Selenium ha un modello client / server in modo da poter avere una serie di macchine virtuali con client Unix, Mac e Windows e la serie di browser comuni a tali ambienti.

Ora, un'applicazione MVC (pattern, non framework) ben progettata mette la logica importante nei modelli e nei controller. In breve, la funzionalità dell'applicazione viene testata quando si verificano questi due aspetti. Le viste tendono ad avere solo la logica di visualizzazione e possono essere facilmente controllate con ispezione visiva. A causa della sottile elaborazione nella vista e della maggior parte dell'applicazione testata bene, molte persone non pensano che il dolore di testare il livello di visualizzazione superi i vantaggi ottenuti da essa.

Detto questo, MVC ha alcune belle strutture per controllare il DOM restituito dalla richiesta. Ciò riduce un po 'il dolore per testare il livello di visualizzazione.

— Berin Loritsch
fonte

1

"Fondamentalmente tutto ciò che devi fare è affermare che l'HTML restituito contiene gli elementi di cui hai bisogno." Questo è esattamente quello che sto cercando di fare e si sta rivelando non banale. Puoi indicare un link in cui funzionerà con una specifica azione del controller invece che renderizzare semplicemente un controllo? (Ho lavorato su un paio di commenti, ma RenderPartial non sta realizzando ciò che voglio fare senza un notevole sovraccarico ..)

— Peter Bernier,

Ti consigliamo di dare un'occhiata a mvccontrib.codeplex.com (MVC Contrib). Ciò fornisce un aiuto non integrato nel linguaggio principale ed è stato raccomandato nel libro "Test-Drive ASP.NET MVC" (programmatori pragmatici). Tuttavia, penso ancora che il selenio sia una soluzione migliore per i test View.

— Berin Loritsch,

TestHelper (MVC Contrib): mvccontrib.codeplex.com/…

— Berin Loritsch

Il selenio (nel mio caso Selenium RC) è quello che userò per i miei test di integrazione. Quello che voglio è che non accada un fallimento prima di quel punto.

— Peter Bernier,

2

@Peter: Il tuo commento sul fatto che i tuoi sforzi siano "non banali" è esattamente il motivo per cui le visualizzazioni dei test unitari sono disapprovate. Di conseguenza, una strategia tipica è quella di rendere le viste il più sottili possibile (ovvero non contenere alcuna logica aziendale), in modo che la maggior parte dei test unitari possa aver luogo altrove (generalmente nel ViewModel). Le viste stesse possono essere verificate mediante ispezione visiva o con uno strumento di test dell'interfaccia utente come il selenio.

— Robert Harvey,

7

Non direi che è malvisto. Piuttosto, quel sentimento è il risultato del fatto che le viste MVC di test unitari (almeno della varietà aspx) sono piuttosto difficili perché le viste aspx hanno troppa dipendenza da WebForms, che a loro volta sono abbastanza non verificabili. Quindi l'argomento sostiene che non vale la pena , perché le opinioni tendono a non essere così complicate.

Naturalmente le viste possono diventare piuttosto complicate, quindi è una tua scelta.

— marcind
fonte

3

Le viste ASP.NET MVC non sono legate ai Webform, per quanto ne so. Uno dei grandi punti di ASP.NET MVC non è che non sono i moduli Web?

— Adam Lear

Il mio punto di vista è che ci vuole più sforzo umano per scrivere i test di integrazione per coprire l'interfaccia utente, che scrivere veri e propri "test unitari" per coprire le opinioni. Ecco perché sto cercando di capire alcune delle resistenze che sembrano essere là fuori verso la scrittura di unit test per i punti di vista.

— Peter Bernier,

Le visualizzazioni di @Anna Aspx sono basate su WebForms. Derivano dalla System.Web.UI.WebControls.Pageclasse, usano i <asp:ContentPlaceholder>controlli ecc. Il modo in cui MVC li esegue evita gran parte della pipeline di esecuzione della Pagina tipicamente associata a WebForms ma utilizza ancora molte cose di WebForms sotto le copertine.

— marcind

Se si utilizza un motore di visualizzazione diverso (come un rasoio), si dovrebbe essere in grado di spostarsi più lontano dal motore Webforms.

— The Muffin Man

6

Non sono sicuro che sia malvisto. La testabilità è uno dei principali vantaggi dell'utilizzo di ASP.NET MVC. Controlla il blog di Steve Sanderson per ulteriori informazioni al riguardo.

Ha anche scritto il miglior libro ASP.MVC (IMO) in assoluto . Non solo insegna a MVC, ma va anche al di là dell'insegnamento delle migliori pratiche al riguardo, comprese le pratiche di test.

Sto pensando di dover chiarire un po 'le visualizzazioni dei test unitari: puoi costruire test unitari intorno al risultato restituito dal controller (ActionResult, ecc.). Sarà comunque necessario eseguire altri test per l'interfaccia utente e l'interazione dell'interfaccia utente effettive.

— Mark Freedman
fonte

"Sarà comunque necessario eseguire altri test per l'interfaccia utente e l'interazione dell'interfaccia utente effettive." Questo è esattamente il mio punto di domanda. Perché i test dell'interfaccia utente diventano improvvisamente parte di "altri test" (ovvero test di integrazione). Avevo visto molti dei contenuti di Steve Sanderson e questo è un po 'quello che mi ha fatto iniziare questo percorso, fondamentalmente cercando di replicare quello che sta facendo con il suo progetto "MvcFakes" e incappando in problemi con il suo codice scritto per le versioni precedenti di MVC. .

— Peter Bernier

1

Puoi imparare come testare la vista restituita da un'azione del controller, come testare i dati di visualizzazione restituiti da un'azione del controller e come verificare se un'azione del controller ti reindirizza o meno a una seconda azione del controller verificando il seguente URL, descrivere in questo breve articolo su Test dei dati di visualizzazione in MVC .

— Jaypee
fonte