Perché il test di MVC Views è disapprovato?

Question

Perché il test di MVC Views è disapprovato?

#1 da (9 voti)
#2 da (7 voti)
#3 da (6 voti)
#4 da (1 voti)

23

Attualmente sto impostando le basi per un'applicazione ASP.Net MVC e sto esaminando il tipo di test unitari che dovrei essere pronto a scrivere. Ho visto in più luoghi persone che dicevano essenzialmente "non preoccuparti di testare le tue opinioni, non c'è logica ed è banale e sarà coperto da un test di integrazione".

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

Scenario di esempio: Diciamo che abbiamo a che fare con un'app CRUD standard con un'entità cliente. Il cliente ha un nome e un indirizzo. Ad ogni livello di test, voglio verificare che la logica di recupero del cliente riceva correttamente sia il nome che l'indirizzo.

Per testare unitamente il repository, scrivo un test di integrazione per colpire il database. Per testare unitamente le regole aziendali, eseguo il mock out del repository, fornisco i dati appropriati delle regole aziendali e verifica che i risultati attesi vengano restituiti.

Cosa mi piacerebbe fare: Per testare l'interfaccia utente, ho preso in giro le regole aziendali, ho impostato la mia istanza cliente prevista, reso la vista e verificato che la vista contenga i valori appropriati per l'istanza che ho specificato.

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

Mi rendo conto che esiste 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 I (o un altro dev) rimuove il campo dell'indirizzo dalla vista, non voglio aspettare che il test di integrazione lo scopra. Voglio che venga scoperto e segnalato in un test unitario che viene eseguito più volte al giorno.

Ho la sensazione di non cogliere un concetto chiave. Qualcuno può spiegare perché volere un feedback di prova immediato sulla validità di una visualizzazione MVC è una cosa negativa? (o se non male, quindi non il modo previsto per ottenere detto feedback)

unit-testing asp.net-mvc

posta Peter Bernier 05.01.2011 - 15:46

fonte

4 risposte

Leggi altre domande sui tag unit-testing asp.net-mvc

C # si fonderà con il compilatore C ++ nativo? [chiuso] Quando (e quando no) usare Wordpress? [chiuso]

score 9 · Answer 1

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. Mentre questo assicura che la pagina HTML sia strutturata come ti aspetti, non verifica completamente l'interfaccia utente.

Un corretto controllo dell'interfaccia utente Web richiede uno strumento come Selenium che utilizzerà i browser sul computer e garantisce che JavaScript e HTML funzionino correttamente in tutti i browser. Il selenio ha un modello client / server in modo da poter avere un set di macchine virtuali con client Unix, Mac e Windows e il set di browser comuni a quegli ambienti.

Ora un'applicazione MVC (pattern, not 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 per avere solo logica di visualizzazione e sono facilmente controllabili con l'ispezione visiva. A causa dell'elaborazione sottile nella vista e della maggior parte dell'applicazione ben testata, molte persone non pensano che il dolore di testare il livello di visualizzazione superi il beneficio che ne deriva.

Detto questo, MVC ha alcune buone strutture per controllare il DOM restituito dalla richiesta. Questo riduce un po 'il dolore per testare il livello di vista.

score 7 · Answer 2

Non direi che è disapprovato. Piuttosto, questo sentimento è il risultato del fatto che le visualizzazioni MVC di test unitari (almeno della varietà aspx) sono piuttosto difficili perché le viste di aspx hanno troppa dipendenza da WebForms, che a loro volta non sono testabili. Quindi l'argomento dice che non è vale lo sforzo perché le opinioni tendono a non essere così complicate.

Ovviamente le visualizzazioni possono diventare piuttosto complicate, quindi è una tua scelta.

score 6 · Answer 3

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

Ha anche scritto il libro ASP.MVC (IMO) a mani libere. Insegna non solo a MVC, ma va anche al di là di insegnare le migliori pratiche che lo riguardano, incluse le pratiche di test.

Penso che sia necessario chiarire un po 'le opinioni dei test unitari: è possibile creare test unitari attorno al risultato restituito dal controller (ActionResult, ecc.). Dovrai comunque eseguire altri test per l'effettiva interazione dell'interfaccia utente e dell'interfaccia utente.

score 1 · Answer 4

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