Utilizzo del solo test dell'interfaccia utente. È ok?

Durante il mio lavoro, abbiamo iniziato a utilizzare i test dell'interfaccia utente oltre ai nostri test di unità e integrazione. Dei tre tipi, i test dell'interfaccia utente richiedono più tempo per scrivere e per eseguire e catturare la minor quantità di errori. Sono anche estremamente fragili, fallendo sporadicamente senza una buona ragione.

Poiché richiedono così tanto tempo per essere eseguiti e non passano in modo coerente, abbiamo scoperto che non valeva la pena di mantenerli. Ovviamente, ciò potrebbe essere dovuto alla scarsa qualità della scrittura dei test dell'interfaccia utente o all'utilizzo di un framework errato (abbiamo utilizzato test dell'interfaccia utente codificata di Visual Studio).

Abbiamo avuto un successo molto migliore con i test di unità e integrazione. Nella tua situazione, dato che il codice non è molto modulare, i test di unità saranno difficili come hai detto. Penso che avresti un successo molto migliore con i integration e test a livello di accettazione (test tutte le funzionalità a un livello appena sotto l'interfaccia utente).

Il problema più grande IMHO di UI Testing in esclusiva è che le permutazioni di cose da testare, anche in un'app relativamente semplice, sono troppo grandi e il livello troppo alto per cogliere molti potenziali difetti. La copertura del codice non sarà molto alta.

Probabilmente troverai e localizzerai alcuni degli elementi principali che inibiranno gli utenti in alcuni scenari (caso migliore, esecuzione del caso peggiore), problemi di convalida e cosa no. Tuttavia, non troverai le cose che dicono che un interruttore utilizzerebbe per svantaggiare la tua applicazione e accedere ai tuoi dati, per esempio.

Test unitario, TDD, Functional Testing e altre metodologie di test sono progettati per testare il codice internamente e ad un livello più granulare. Ciò rende il test più completo e in grado di catturare i bug più insidiosi che mancheranno solo i semplici test dell'interfaccia utente. Una combinazione di quanto sopra è la soluzione migliore. Purtroppo non sembra che dovrai fare molta scelta a meno che tu non lo faccia. Sembra che ci siano dei limiti di tempo severi così com'è, ma tieni presente che con il solo test dell'interfaccia utente il tuo tempo può essere eseguito indipendentemente.

Vorrei raccomandare di prendere in mano Michael Feathers Lavorare efficacemente con il codice legacy . Nel libro definisce "codice legacy", in qualche modo interessante per me, come "codice senza prove". L'impressione che ottengo è che la tua situazione è abbastanza comune: non solo il tuo codice non è coperto dai test, ma nel suo stato attuale non può essere coperto dai test. Il libro descrive alcuni modi per affrontare questa situazione. Non li elenco qui perché a) sono complicati e b) non sono impegnati nella mia memoria.

Quello che faccio se fossi in te è mettere un po 'del codice in una "imbracatura di test". All'inizio non mi preoccuperei nemmeno di aggiungere test significativi. Basta arrivare al punto in cui si hanno uno o due test unitari per testare parti banali del sistema. Una volta che hai quella piccola testa di ponte, da lì si tratta principalmente di espandere il lavoro che hai già fatto (per non dire che è facile). Potrebbe sembrare inutile all'inizio, ma alcuni test semi-privi di significato sono meglio di nessun test, e forse dopo qualche refactoring graduale avrai dei test significativi.

I test dell'interfaccia utente non sono quello che stai cercando. Per ottenere il codice legacy in prova, si inizia a scrivere Test di accettazione. Si tratta di test blackbox sul livello esterno, ma ampiamente indipendenti dall'interfaccia utente. Puoi dare un'occhiata a strumenti come Cetriolo per avere un'idea dell'approccio.

Mentre procederai al refactoring e migliorerai il codice, dovresti aggiungere test di unità e di integrazione per il nuovo codice mentre procedi.