Come posso testare un'unità di una GUI?

https://stackoverflow.com/questions/215458

03-07-2019
|

Domanda

I calcoli nel mio codice sono ben testati, ma poiché c'è così tanto codice GUI, la mia copertura complessiva del codice è inferiore a quella che vorrei. Ci sono delle linee guida sul codice della GUI di unit test? Ha anche senso?

Ad esempio, ci sono grafici nella mia app. Non sono stato in grado di capire come automatizzare il test dei grafici. Ci vuole un occhio umano, AFAIK, per verificare se il grafico è corretto.

(sto usando Java Swing)

Soluzione

Disegni come MVP e MVC in genere cercano di estrarre quanta più logica possibile dalla GUI effettiva. Un articolo molto popolare su questo è " The Humble Dialog Box " di Michael Feathers. Personalmente ho avuto esperienze contrastanti con il tentativo di spostare la logica fuori dall'interfaccia utente - a volte ha funzionato molto bene, altre volte ha comportato più problemi di quanti ne valga la pena. È in qualche modo al di fuori della mia area di competenza.

Altri suggerimenti

Ovviamente, la risposta è usare MVC e spostare quanta più logica possibile dalla GUI.

Detto questo, molto tempo fa ho sentito da un collega che quando SGI stava eseguendo il porting di OpenGL su un nuovo hardware, avevano un sacco di test unitari che avrebbero disegnato una serie di primitive sullo schermo e poi calcolato una somma MD5 del frame buffer. Questo valore potrebbe quindi essere confrontato con valori hash noti noti per determinare rapidamente se l'API è accurata per pixel.

Puoi provare UISpec4J è una libreria Open Source funzionale e / o di test di unità per applicazioni Java basate su Swing ...

Ecco alcuni suggerimenti:

Prova a rimuovere la maggior parte del codice che puoi dalla GUI (con controller e oggetto modello) in questo modo sarai in grado di testarli senza la GUI.

Per l'immagine, è necessario verificare il valore fornito al codice che genera l'immagine.

Puoi provare a usare Cucumber e Swinger per la scrittura di test di accettazione funzionale in inglese per le applicazioni della GUI di Swing. Swinger utilizza la libreria Jemmy di Netbeans sotto il cofano per guidare l'app.

Il cetriolo ti consente di scrivere test come questo:

 Scenario: Dialog manipulation
    Given the frame "SwingSet" is visible
    When I click the menu "File/About"
    Then I should see the dialog "About Swing!"
    When I click the button "OK"
    Then I should not see the dialog "About Swing!"

Dai un'occhiata a questo Demo video swinger per vederlo in azione.

Esiste Selenium RC , che automatizzerà il test di un'interfaccia utente basata sul web. Registra le azioni e le riproduce. Dovrai comunque esaminare le interazioni con la tua interfaccia utente, quindi questo non aiuterà con la copertura, ma può essere utilizzato per build automatizzate.

Il test è una forma d'arte. Sono d'accordo che la logica dovrebbe essere rimossa la GUI il più possibile. Possiamo quindi concentrare i nostri test unitari lì. Come qualsiasi altra cosa, i test riguardano la riduzione del rischio. Non è sempre necessario testare tutto, ma molte volte la cosa migliore è interrompere i diversi test in diverse aree.

L'altra domanda è cosa stai davvero cercando di testare a livello di interfaccia utente. Il test dell'interfaccia utente è il test più costoso perché di solito richiede più tempo per creare, mantenere ed è il più fragile. Se testate la logica per sapere che le coordinate sono corrette prima di provare a tracciare la linea, cosa state testando specificamente? Se si desidera testare un grafico con una linea rossa viene disegnato. Puoi dargli un set di coordinate predeterminate e testare se alcuni pixel sono rossi o non rossi? Come suggerito sopra i confronti di bitmap funzionano, Selenium ma il mio obiettivo principale non è quello di testare eccessivamente la GUI ma piuttosto testare la logica che aiuterà a creare l'interfaccia utente e quindi concentrarsi su quale parte dell'interfaccia utente si rompe o è sospetta e focalizzare una manciata di test lì.

Puoi utilizzare JFCUnit per testare la tua GUI, ma la grafica può essere più impegnativa. In alcune occasioni ho scattato istantanee della mia GUI e l'ho confrontata automaticamente con una versione precedente. Sebbene ciò non fornisca un test effettivo, ti avvisa se una generazione automatica non riesce a produrre l'output previsto.

Quello che raccolgo dalla tua domanda è che stai cercando un modo automatizzato per testare in dettaglio il tuo comportamento della GUI, l'esempio che dai è testare se una curva è effettivamente disegnata correttamente.

I framework di unit test forniscono un modo per eseguire test automatici, ma penso che il tipo di test che vuoi fare siano test di integrazione complicati che verificano il corretto comportamento di una moltitudine di classi, tra cui le classi del tuo toolkit / libreria GUI , che non dovresti provare.

Le tue opzioni dipendono molto da quali piattaforme / toolkit / framework usi: ad esempio, un'applicazione che usa Qt come framework GUI può usare Squish per automatizzare i suoi test. Verifichi i risultati dei test una volta e i successivi test eseguiti automaticamente confrontano i risultati con i risultati verificati.

Window Licker per Swing & amp; Ajax

Da quello che so, questo è abbastanza complicato e dipende molto dalla lingua: numerose lingue hanno il loro modo di testare la GUI, ma se hai davvero bisogno di testare la GUI (al contrario dell'interazione modello / gui), tu spesso devono simulare un utente facendo clic sui pulsanti. Ad esempio, il framework SWT utilizzato in Eclipse fornisce SWTBot , JFCUnit è già stato menzionato, Mozilla ha il suo modo di simulare questo in XUL (e da quello che ho letto sui loro blog, questi i test sembrano essere piuttosto fragili).

A volte devi fare uno screenshot e testare il rendering perfetto per i pixel (credo che Mozilla lo faccia per verificare la corretta visualizzazione delle pagine) - questo richiede una configurazione più lunga, ma potrebbe essere quello che ti serve per i grafici. In questo modo, quando aggiorni il tuo codice e si interrompe un test, devi controllare manualmente l'immagine se l'errore era reale o hai migliorato il codice di rendering del grafico per generare grafici più carini e devi aggiornare gli screenshot.

Se stai usando Swing, FEST-Swing è utile per guidare la tua GUI e testare asserzioni. È abbastanza semplice testare cose come " se faccio clic sul pulsante A, dovrebbe essere visualizzata la finestra di dialogo B " o " se seleziono l'opzione 2 dal menu a discesa, tutte le caselle di controllo dovrebbe essere deselezionato " .

Lo scenario grafico che hai citato non è così facile da testare. È abbastanza facile ottenere la copertura del codice per i componenti della GUI semplicemente creando e visualizzandoli (e magari guidandoli con FEST). Tuttavia, fare affermazioni significative è la parte difficile (e la copertura del codice senza asserzioni significative è un esercizio di autoinganno). Come si può verificare che il grafico non sia stato disegnato capovolto o troppo piccolo?

Penso che devi solo accettare che alcuni aspetti delle GUI non possono essere testati in modo efficace con test unitari automatizzati e che dovrai testarli in altri modi.

Non è compito tuo testare la libreria della GUI. Quindi puoi evitare la responsabilità di controllare ciò che è effettivamente disegnato sullo schermo e controllare invece le proprietà dei widget, fidandoti della libreria che rappresentano accuratamente ciò che viene disegnato.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow