Come si esegue l'unittest su un'app Tkinter?

Question

Ho appena iniziato a studiare su TDD e sto sviluppando un programma utilizzando una GUI di Tkinter. L'unico problema è che una volta chiamato il metodo .mainloop(), la suite di test si blocca fino a quando la finestra non viene chiusa.

Ecco un esempio del mio codice:

# server.py 
import Tkinter as tk 

class Server(tk.Tk): 
    def __init__(self): 
     tk.Tk.__init__(self) 
     self.mainloop() 

# test.py 
import unittest 
import server 

class ServerTestCase(unittest.TestCase): 
    def testClassSetup(self): 
     server.Server() 
     # and of course I can't call any server.whatever functions here 

if __name__ == '__main__': 
    unittest.main() 

Allora, qual è il modo appropriato di applicazioni di test Tkinter? O è solo 'non farlo'?

Grazie!

Answer 1

Una cosa che si può fare è generare il mainloop in un thread separato e usare il thread principale per eseguire i test effettivi; guarda il thread mainloop come se fosse. Assicurati di controllare lo stato della finestra di Tk prima di fare il tuo asser.

Multithreading qualsiasi codice è difficile. Potresti voler spezzare il tuo programma Tk in pezzi testabili invece di testare l'intera unità contemporaneamente (il che non è in realtà un test unitario).

Vorrei infine suggerire test almeno a livello di controllo se non inferiore per il tuo programma, ti aiuterà moltissimo.

Answer 2

C'è una tecnica chiamata patch di scimmia, per cui si cambia codice in fase di esecuzione.

È possibile eseguire il patch delle scimmie sulla classe TK, in modo che mainloop non avvii effettivamente il programma.

Qualcosa di simile nella vostra test.py (non testata!):

import tk 
class FakeTk(object): 
    def mainloop(self): 
     pass 

tk.__dict__['Tk'] = FakeTk 
import server 

def test_server(): 
    s = server.Server() 
    server.mainloop() # shouldn't endless loop on you now... 

Un quadro di scherno come mock rende questo molto meno doloroso.

Answer 3

@Ryan La risposta di Ginstrom cita finta. Questa ricetta Active State mostra come simulare evita il problema dell'OP della suite di test sospesa: Robust Unittesting of Tkinter Menu Items with Mocking. La suite di test in questa ricetta non include alcuna chiamata a mainloop.

Answer 4

Bottom line: pompare gli eventi con il codice seguente dopo un'azione che causa un evento UI, prima di un'azione successiva che richiede l'effetto di quell'evento.

---

IPython fornisce una soluzione elegante senza fili è il suo gui tk implementazione del comando di magia che con ubicazione nel terminal/pt_inputhooks/tk.py.

Invece di root.mainloop(), viene eseguito root.dooneevent() è un ciclo, che verifica la condizione di uscita (un input interattivo in arrivo) ogni iterazione. In questo modo, il ciclo pari non viene eseguito quando IPython è impegnato a elaborare un comando.

Con i test, non c'è nessun evento esterno da attendere e il test è sempre "occupato", quindi è necessario eseguire manualmente (o semi-automaticamente) il ciclo in "momenti appropriati". Quali sono?

Il test mostra che senza un ciclo di eventi, è possibile modificare direttamente i widget (con <widget>.tk.call() e qualsiasi cosa lo avvolga), ma i gestori di eventi non si attivano mai. Quindi, il ciclo deve essere eseguito ogni volta che si verifica un evento e abbiamo bisogno del suo effetto - ad esempio dopo ogni operazione che cambia qualcosa.

Il codice, derivato dalla suddetta procedura IPython, sarebbe:

def pump_events(root): 
    while root.dooneevent(_tkinter.ALL_EVENTS|_tkinter.DONT_WAIT): 
     pass 

grado di trattare (eseguire dei gestori per) tutti gli eventi in sospeso, e tutti gli eventi che potrebbero derivare da quelli direttamente.

(tkinter.Tk.dooneevent() delegati al Tcl_DoOneEvent().)