test dell'interfaccia utente può essere lento, fragile e doloroso per mantenere, ma alcuni bug possono essere catturati soltanto nei test dell'interfaccia utente. La questione importante non è se valga la pena di scrivere test dell'interfaccia utente, ma come mantenere i vostri test dell'interfaccia utente utili, stabili e mantenibili.
Un errore comune è utilizzare i test dell'interfaccia utente come sostituto per altri test. In teoria, puoi testare molte funzionalità attraverso i test dell'interfaccia utente, ma ci sono molti problemi con questo approccio. Per i principianti, alcune funzionalità potrebbero essere molto difficili da testare direttamente nell'interfaccia utente (in particolare condizioni eccezionali). In secondo luogo, se un test fallisce, spesso è difficile capire quale sia la fonte del problema. Infine, più percorsi di codice vengono testati nei test dell'interfaccia utente, più lenti diventano i test dell'interfaccia utente. Se fai affidamento solo su test lenti, la tua produttività peggiora, il che aumenta la tentazione di "provvisori" disattivare i test non funzionanti.
Il mio consiglio è di testare il più possibile in unit test e test di integrazione, creare una buona separazione tra l'interfaccia utente e la logica di business e utilizzare i test dell'interfaccia utente per rilevare/prevenire bug che non possono essere testati in altri tipi di test.
Se si dispone di molti test, prendere in considerazione la creazione di più suite. Creo una suite per i test dell'interfaccia utente, uno per i test di integrazione e uno per i test delle unità. I test unitari sono molto veloci, quindi li eseguo mentre sviluppo il mio codice (spesso tramite TDD). Questi sono i test che mi aiutano a essere produttivi.
I test di integrazione vengono eseguiti meno spesso (forse dopo aver implementato un po 'di modifiche). I test dell'interfaccia utente vengono eseguiti quando mi sto preparando a inviare una modifica (o quando scrivo più test dell'interfaccia utente, ovviamente).
Un ultimo consiglio: considera la scrittura dei test dell'interfaccia utente con Domain Specific Language. Ciò semplifica la comprensione dei test (perché vengono letti come un insieme di passaggi utente e non come un gruppo di azioni browser di basso livello). Inoltre, può rendere il codice più facile da mantenere. Ad esempio, invece di sottoporre tutti i test alle azioni del browser passo per passo per accedere all'utente, potresti vedere:
LoginPage loginPage = new LoginPage(selenium);
HomePage homePage = loginPage
.enterUserName(TestUsers.Alice.USER_NAME)
.enterPassword(TestUsers.Alice.PASSWORD)
.submit();
assertThat(homePage.getBreadcrumbs(), equalTo("Home"));