Come posso scrivere un test unitario di una GUI in Xcode?

Question

Voglio scrivere un test unitario della sola parte della GUI della mia applicazione Cocoa.

Nel test dell'unità di testo, c'è una struttura di test e un caso di test che chiama l'unità in prova. Tutto il codice al di sotto di quell'unità viene preso in giro. Quindi, sia l'input che l'output sono controllati e monitorati; viene testato solo il codice nell'unità in prova.

Voglio fare la stessa cosa in cui l'unità sotto test è la mia GUI:
1) Configurare una sorta di framework in cui posso scrivere codice che manipolerà e ispezionerà i controlli della GUI.
2) Connetti i miei controlli della GUI ai gesti del mio codice attuale, non alle istanze reali.
3) Eseguire il test, che manipola i controlli e quindi controlla l'oggetto fittizio per vedere se sono stati chiamati i metodi corretti con i parametri corretti e controlla la GUI per vedere se le risposte dall'oggetto simulato causano le modifiche corrette nei widget .

Chiunque faccia questo? Se é cosi, come? Qualche idea su come potrei fare questo?

Grazie,

Pat

(Edit) Per fare un esempio molto specifico, voglio:
1) Scrivi un banco di prova che selezionerà la voce di menu 'MyMenu' -> 'MyItem '. In questo test case, voglio verificare che il metodo [AppDelegate doMyItem] venga chiamato esattamente una volta e che nessun altro metodo in AppDelegate venga chiamato.
2) Genera un oggetto fittizio di AppDelegate. (So ​​come farlo)
3) In qualche modo (con il quale eseguire il handwaving qui) collegare la mia applicazione in modo che un'istanza di simulazione di AppDelegate sia collegata al posto di quella reale.
4) Eseguire il test. Guardalo fallire perché 1) Non ho ancora creato MyMenu. 2) Non ho ancora creato MyItem. 3) Non ho fatto il lavoro di IB per connettere MyItem a [AppDelegate doMyItem], o 4) perché non ho ancora scritto il metodo 'doMyItem'.
5) Correggere i quattro problemi precedenti (uno alla volta se mi sento davvero pedante quel giorno).
6) Esegui nuovamente il test e guardalo avere successo.

Ciò rende chiara la domanda?

Answer 1

Ecco un paio di modi comuni per farlo in generale (dovrebbe funzionare con la maggior parte se non tutte le lingue compatibili con il cacao).

1 - creare un'interfaccia di callback. Uno degli input durante la creazione degli elementi della GUI è un'implementazione di questa interfaccia. Quando c'è un'interazione dell'utente, l'elemento della GUI chiama una funzione di aggiornamento su tale interfaccia. Avere un'implementazione reale e un'implementazione di test.

2 - Utilizzare i gestori di eventi. Registrare tutti gli elementi della GUI con uno o più gestori di eventi e fare in modo che la GUI generi eventi sull'interazione dell'utente. Avere un'interfaccia del gestore di eventi con due implementazioni, ancora una per l'uso reale e una per il test.

Modifica: whoops, mancato requisito # 1. Mai fatto con controlli specifici per OSX, ma in generale ci sono due approcci.

1 - crea uno script o un'app che genera un input simile all'utente. Ha l'inconveniente di non essere facile da ispezionare effettivamente la GUI. Devi invece generare buoni casi di test per assicurarti che tutto ciò che dovrebbe esserci sia e che non ci sia nulla in più.

2 - creare un'interfaccia con un'implementazione di test che sostituisce il livello di rendering e di interfaccia. Questo è più facile con librerie come SDL o directFB e meno con cose come l'API OSX, API win32, ecc.

Modifica: risponde alla modifica in questione.

Nel caso del vostro esempio, utilizzando un separati test app e gestori di eventi ecco come sarebbe guardare:

L'applicazione di test è una semplice applicazione o script che si avvia la vostra interfaccia grafica e quindi genera mouse/tastiera eventi basati su file di input. Come ho già detto, non l'ho mai fatto in OSX (solo QNX). Con un po 'di fortuna sarai in grado di generare eventi mouse e tastiera con l'API, ma dovrai chiedere a qualcun altro se è possibile.

Quindi crea un input per il tuo test-case. L'app di test analizzerà questo per sapere cosa fare. Può essere semplice XML come questo:

<testcase name="blah"><mouseevent x="120" y="175" type="click"/></testcase> 

o qualsiasi sia la sequenza del mouse in realtà.

Quando lo script esegue tale comando, farà clic con il mouse su quel pulsante. Il tuo gestore di eventi prenderà in considerazione questo. Ma ora dovresti eseguire la tua app con un flag --test o somesuch in modo che utilizzi effettivamente il gestore di eventi di test. Invece di fare qualsiasi cosa la tua app normalmente, il gestore di eventi di test può eseguire alcune azioni personalizzate. Ad esempio, potrebbe eseguire alcune delle normali azioni (è comunque necessaria la GUI per rispondere) e quindi inviare un messaggio (tramite socket, pipe, qualunque) all'app di test.

L'app di test raccoglierà questo messaggio e lo confronterà con ciò che si aspetta di vedere. Così ora forse il tuo XML testcase è simile al seguente:

<testcase name="blah"> 
    <mouseevent x="120" y="175" type="click"/> 
    <response>doMyItem() called</response> 
</testcase> 

Se la risposta generata dal gestore di eventi è diverso, allora il caso di test non è riuscito. È possibile stampare la risposta effettiva per aiutare nel debug.

Answer 2

due principi, due links:

• rendere la vista muto come possibile, con il modello passive view: questo rende più facile interfaccia grafica per testare
• : Fiducia implementazione di cacao di pulsanti, menu, .. Ma verificare che target and action sia connesso correttamente, che bindings sono come previsto.

Answer 3

Hai esaminato il quadro dell'accessibilità? Dovrebbe consentire a un'applicazione di ispezionare l'interfaccia utente di un'altra applicazione e generare eventi di interazione simili all'utente.

Accessibility Overview