Unit Testing User Interface. Qual è un modo efficace?

Question

Ho un'applicazione client/server di gestione stipendi & dove esistono diversi moduli di input con regole di convalida dei dati complesse. Sto trovando un modo efficace per eseguire test unitari dell'interfaccia utente.

Per le regole di convalida complesse voglio dire:

• "Disabilita tasto X Se inserisco un valore nel campo di testo Y"
• "Attiva una casella combinata se inserisco un valore in un campo di testo" ... ... ......

modello più promettente che ho trovato è suggerito da M. Fowler (http://martinfowler.com/eaaDev/ModelViewPresenter.html).

Hai qualche esperienza in merito al test dell'unità dell'interfaccia utente? Come stack di tecnologia che sto utilizzando: .NET 3.5 & Libreria Widget di Windows Form.

Answer 1

Non lo chiamerei "unit test" esattamente, ma ho avuto un certo grado di successo con l'esecuzione di test automatici contro un'interfaccia utente di WinForms e anche nell'interfaccia utente web che utilizza WatiN.

Supponendo che è possibile ottenere un handle per la finestra dell'applicazione che si desidera testare, si dovrebbe essere in grado di codificare un sacco di codice C# per testare la funzionalità dell'interfaccia utente.

Molte persone condannano l'idea di provare a eseguire test automatici contro un'interfaccia utente, perché c'è così tanto che non è possibile testare in questo modo. Ad esempio, nessun test automatico noterà che un font è brutto o che un testo è confuso o un pulsante è leggermente fuori centro. Non c'è dubbio, per questi tipi di cose hai sicuramente bisogno di una persona umana intelligente che guardi lo schermo.

Tuttavia, a parte questo tipo di test, c'è sicuramente una vasta gamma di test ripetitivi che possono essere automatizzati ed eseguiti regolarmente. La maggior parte delle applicazioni di grandi dimensioni ha un intero batch di script di test di regressione che devono essere eseguiti manualmente ogni volta che una nuova release sta per uscire. Questi test sono di solito qualcosa da addestrare a fare una scimmia, solo un elenco di istruzioni per fare clic su questo link, inserire del testo, fare clic su questo pulsante, controllare il messaggio risultante, ecc. Queste cose sono terribilmente sprecate nel tempo del tester di QA, e li rende infelici, quindi se possono essere automatizzati, fantastico. Questi tipi di test dovrebbero essere in grado di essere eseguiti automaticamente dal tuo server di build ogni giorno e potrebbero essere realizzati in modo molto più approfondito rispetto a qualsiasi test manuale.

Ancora una volta, non troverà strane cose inaspettate, ma ti darà un certo livello di sicurezza che il tuo piccolo cambiamento non ha infranto altri schermi che non hai mai sentito sull'altro lato dell'applicazione.

Concesso, questo risulta in un lavoro più continuo per gli sviluppatori, poiché piccole modifiche all'applicazione potrebbero interrompere i test per motivi stupidi, proprio come qualsiasi test automatico, ma dovrebbe far risparmiare un sacco di tempo in testing e debug. Se questo valga la pena per voi è per voi da decidere, ma penso che sia una considerazione che non dovrebbe essere liquidata con la stessa rapidità con cui normalmente si vede.

Answer 2

Il test delle unità non è ottimale per il test di un'interfaccia, per definizione. I test unitari dovrebbero testare la funzionalità di back-end di una singola entità. Per i test funzionali, ottenere un quadro per farlo. Prendi in considerazione cose come Mercury (ora HP) Quality Center o Performance Center. Se hai un budget, prova Selenium.

I test funzionali sono un passo avanti rispetto ai test unitari e non devono essere confusi tra loro.

Answer 3

Il test dell'interfaccia utente è difficile e generalmente è meglio farlo a un livello di test più elevato rispetto al test dell'unità.

Testare i controller e la logica utilizzando la separazione MVC/MVP suggerita da Martin Fowler è un ottimo inizio, ma spesso è necessario aumentare questo con strumenti di automazione come WinRunner o QTP per testare completamente l'interfaccia utente in modo automatico.

Answer 4

Per le regole di convalida complesse voglio dire:

* "Disable button X if I Insert a value in textfield Y" 

Queste regole testare sia per modello e vista, e questo è ciò che li rende difficili. Invece, convalidare che quando si inserisce un valore nel campo di testo Y, il modello acquisisce quel valore; che un modello con Y vuota ha X_ENABLED == false, e con Y non vuota ha X_ENABLED == true; e che, dato un modello con X_ENABLED == true, il pulsante Visualizza è abilitato. Solo due di questi test coinvolgono l'interfaccia utente e dovrebbero essere così semplici da non poter fallire. Metti la logica complessa nel modello in cui è facilmente testata.

Answer 5

Untit test l'interfaccia utente è, come altri hanno detto, un dolore. Vorrei solo aggiungere che la nuova funzione Test & Lab Manager di Team Foundation 2010 è un ottimo modo per eseguire sia il test manuale dell'interfaccia utente che lo automatizzando i test successivi a. È abbastanza intelligente da riconoscere le strutture della GUI durante l'esecuzione dei test, almeno per WinForms, WPF e siti Web.