¿Cómo ejecuto unittest en una aplicación Tkinter?

Question

Acabo de comenzar a aprender sobre TDD, y estoy desarrollando un programa usando una GUI de Tkinter. El único problema es que una vez que se llama al método .mainloop(), el banco de pruebas se cuelga hasta que se cierra la ventana.

Aquí es un ejemplo de mi código:

# 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() 

Entonces, ¿cuál es la forma adecuada de aplicaciones de pruebas Tkinter? ¿O es simplemente 'no'?

Gracias!

Answer 1

Una cosa que puede hacer es generar el mainloop en un hilo separado y utilizar el hilo principal para ejecutar las pruebas reales; mira el hilo del lazo principal por así decirlo. Asegúrese de verificar el estado de la ventana Tk antes de hacer sus afirmaciones.

Multithreading cualquier código es difícil. Es posible que desee dividir su programa Tk en partes comprobables en lugar de probar todas las unidades a la vez (lo que realmente no es una prueba unitaria).

Me finalmente sugerir las pruebas al menos en el nivel de control si no más bajo para su programa, que le ayudará enormemente.

Answer 2

Hay una técnica llamada mono-parches, mediante el cual se cambia el código en tiempo de ejecución.

Usted podría mono-parchear la clase TK, de modo que en realidad no mainloop iniciar el programa.

Algo como esto en su test.py (no probado!):

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 marco de burla como mock hace esto mucho menos doloroso.

Answer 3

@Ryan La respuesta de Ginstrom es falsa. Esta receta de estado activo muestra cómo el simulacro evita el problema de OP del conjunto de pruebas colgantes: Robust Unittesting of Tkinter Menu Items with Mocking. El conjunto de pruebas en esta receta no incluye ninguna llamada al mainloop.

Answer 4

Resultado final: bombee los eventos con el siguiente código después de una acción que causa un evento UI, antes de una acción posterior que necesita el efecto de ese evento.

---

IPython ofrece una solución elegante sin hilos que su aplicación gui tk comando mágico que se encuentra en terminal/pt_inputhooks/tk.py.

En lugar de root.mainloop(), ejecuta root.dooneevent() es un bucle, verificando la condición de salida (una entrada interactiva que llega) en cada iteración. De esta forma, el bucle par no se ejecuta cuando IPython está ocupado procesando un comando.

Con las pruebas, no hay eventos externos que esperar, y la prueba siempre está "ocupada", por lo que uno tiene que ejecutar manualmente (o semiautomáticamente) el ciclo en "momentos apropiados". ¿Qué son?

Las pruebas muestran que sin un bucle de evento, uno puede cambiar los widgets directamente (con <widget>.tk.call() y todo lo que lo envuelve), pero los controladores de eventos nunca se activan. Por lo tanto, el ciclo debe ejecutarse cada vez que ocurre un evento y necesitamos su efecto, es decir, después de cualquier operación que cambie algo.

El código, derivado del procedimiento IPython antes mencionado, sería:

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

Eso sería procesar (ejecutar manejadores de) todos los eventos pendientes, y todos los eventos que resulten directamente de estas.

(tkinter.Tk.dooneevent() delegados a Tcl_DoOneEvent().)