Dovrei preoccuparmi di scrivere un test unitario per i componenti UI / UX?

Question

Dovrei preoccuparmi di scrivere un test unitario per i componenti UI / UX?

#1 da (2 voti)
#2 da (-1 voti)

3

Quindi sto costruendo un'applicazione con Angular e ho iniziato a fare il test dell'interfaccia utente con DalekJS ( link ). Mentre scrivo questi test ho pensato a me stesso, dovrei anche preoccuparmi di scrivere unit test che sono componenti UI / UX.

Ora i miei servizi angolari in genere non hanno nulla a che fare con il DOM o il rendering diretto della pagina in modo tale da testare l'unità e ha senso, tuttavia le direttive angolari sono componenti che rendono le cose direttamente alla pagina e scrivono le unit test sembra 1. Non è un modo efficace per testare i componenti UI / UX e 2. Si sovrapporrebbe ai test UI / UX.

Per il punto n. 1, unit test (almeno quelli che ho visto) in realtà non scrive nulla su un browser e lo rende. Per cose che richiedono DOM, generalmente prendi in giro il DOM in una variabile e usalo per testare tutto ciò che devi testare. Se si verifica un errore con un test, non è possibile caricarlo in un browser e giocarci come con i test UI / UX (che nella mia esperienza funziona con codice che è la vera applicazione che esegue il rendering e tutto) .

Per il punto 2, una delle mie direttive ha una proprietà chiamata contentVisible. Ora posso scrivere un test unitario per assicurarmi che la proprietà sia il valore corretto in determinati punti, ma in realtà non testare ciò che voglio veramente testare, perché anche se contentVisible è impostato su false, il contenuto potrebbe ancora essere sottoposto a rendering schermata che il test UI / UX avrebbe rilevato.

Vale ancora la pena di scrivere un test unitario per i componenti UI / UX in cui i test dell'interfaccia utente sarebbero in grado di raccogliere tutto ciò che il test unitario sarebbe anche fare un lavoro migliore dal momento che può testare ciò che è effettivamente reso?

eccezione L'unica eccezione in cui avrei bisogno di un test unitario è per certe richieste di ajax. Ad esempio, assicurandoti che una richiesta di ajax non sia costituita da una richiesta di ajax che non viene eseguita e le modifiche all'interfaccia utente sono cose che possono essere verificate solo con test di unità.

testing unit-testing

posta ryanzec 05.08.2013 - 19:55

fonte

2 risposte

Leggi altre domande sui tag testing unit-testing

Come rappresentare graficamente i giorni e l'ora per un progetto che ho fatto Possibile con PHP MVC Framework? Una soluzione migliore per l''override' del client delle funzionalità di base?

score 2 · Answer 1

La mia risposta fuzzy è che a volte avere test delle unità dell'interfaccia utente è una buona idea, per alcune parti dell'interfaccia utente. Nella mia esperienza:

Spesso le persone responsabili dei test funzionali e di integrazione sono persone diverse da quelle responsabili dei test unitari (in genere, QA vs. Dev). In quanto tali, ognuno può individuare aree diverse (e avere diversi punti ciechi) su ciò che dovrebbe essere coperto dai test.
In relazione a questo, i programmatori dovrebbero essere responsabili di testare il proprio codice e non rimandare alcuni aspetti semplicemente perché qualcun altro sta teoricamente testando quel codice.
I test unitari sono più mirati dei test funzionali completi. Mentre quest'ultimo potrebbe dirti che un bottone atteso non è cliccabile, non ti dirà istantaneamente che questo è perché è enabled proprietà è falso vs. è z-index è sbagliato vs. le sue coordinate di layout sono al di fuori del viewport, ecc. Allo stesso modo, come si fa notare, il test unitario può dirvi che la proprietà visible è impostata correttamente, ma non indica necessariamente se l'oggetto è effettivamente visibile (sebbene tali test siano possibili). In altre parole, anche con esempi banali si può vedere che i due tipi di test non sono intercambiabili.
Gli approcci a cinghia e bretelle vanno spesso bene [per gli ingegneri del software].
Provare a testare qualsiasi aspetto del codice - GUI, basato sul tempo, asincrono - tenderà a migliorare il proprio pensiero su quel codice e sul suo design. Il compromesso è che troppi test o test sul livello errato di astrazione possono rallentare il refactoring. Ma imho è di alto valore per provare per testare qualsiasi parte e imparare dall'esperienza quali tipi di test aggiungono più valore.

Ho lavorato su un paio di grandi progetti in cui l'unità dei programmatori verificava molte parti dell'interfaccia utente salvate molto tempo e rendeva le persone del QA più felici (e in grado di concentrarsi maggiormente sulle cose che i programmatori non potevano individuare altrettanto facilmente). Dovrei aggiungere, io faccio non come testare il codice UI perché è lungo e difficile. In generale, i test di scrittura richiedono molto tempo, ma si ripagano rapidamente, e i buoni test delle unità dell'interfaccia utente che aggiungono specificità a ciò che gli strumenti funzionali possono testare non fanno eccezione.

score -1 · Answer 2

Sarebbe completamente inutile scrivere test unitari per i componenti UI / UX. Per i componenti UI / UX dovresti scrivere i test dell'interfaccia utente utilizzando uno strumento di registrazione del browser come Selenium o qualcosa del genere. Se stai effettuando chiamate AJAX al back-end, i metodi chiamati dovrebbero avere test unitari. Verifica sempre l'app dal punto di vista dell'utente, quindi lavora all'indietro.