PyUseCase

PyUseCase es un software de prueba de GUI para PyGTK.
pruebas GUI Mantenible con un caso de uso del registrador
Grabación de la intención más que la mecánica
La forma más natural para crear pruebas a través de una interfaz de usuario es simplemente llevar a cabo las acciones que desea realizar y disponer de una herramienta que puede grabar y luego reproducirlas posteriormente. Esta es una forma sencilla y rápida de crear pruebas de GUI y existen muchas herramientas que hacen esto.
La mayoría de las herramientas par las pruebas con fuerza a la interfaz gráfica de usuario
Los problemas comienzan cuando se tiene un par de pruebas y sus cambios GUI. La grabación puede ser una gran manera de crear pruebas, pero es una terrible manera de mantener un gran número de ellos. Es propenso a errores, frustrante y consume mucho tiempo una vez que tenga algunas pruebas. La primera generación de herramientas de grabado posiciones de pixel y se rompió tan pronto como usted cambió su resolución de pantalla. Herramientas oferta de hoy en términos de la mecánica de la GUI: encontrar una mesa con un cierto nombre y haga clic en la tercera columna de la cuarta fila. Pueden sobrevivir los cambios de pantalla y re-arreglos menores de la interfaz gráfica de usuario, pero no mucho más. Los scripts grabados son densos y no transmiten el propósito de la prueba, y son un libro cerrado para todas las personas no técnicas (ya veces para todo el mundo excepto el autor de la herramienta).
El problema es esencialmente uno de acoplamiento. Las pruebas y la GUI están estrechamente acopladas entre sí y no pueden cómodamente variar independientemente uno de otro. Este punto se hace así por Robert C. Martin en su blog aquí y su conclusión es que las pruebas de interfaz gráfica de usuario es inherentemente frágil y usted debe hacer tan poco de ella como usted puede conseguir lejos con.
Esto parece más bien derrotista embargo. Existe un enorme valor en ser capaz de demostrar lo que hacen sus pruebas a un usuario del sistema. Si las pruebas eludir la interfaz de usuario a continuación, ese proceso requiere una buena cantidad de habilidad técnica y una gran cantidad de confianza de la parte de su usuario. Y de todos modos, los desarrolladores de software a resolver problemas de acoplamiento todo el tiempo. La respuesta es, como de costumbre, para introducir otro nivel de indirección.
Rompiendo el acoplamiento con un mapa de interfaz de usuario
La gente de negocios y usuarios en general, trabajar en casos de uso. Estas son las descripciones de alto nivel de una secuencia de acciones en un idioma que comprendan: es decir, la del dominio. Por tanto, la idea de un "caso de uso Recorder" es una herramienta que puede grabar y reproducir tales secuencias y con ello captar la intención del usuario. Esto permitirá una mayor comprensión, una menor dependencia de la forma exacta de la GUI y fácil ajuste de las pruebas existentes sin tener que recurrir a hacer clic en todos los botones de nuevo.
El mecanismo básico es que mantenemos una correspondencia entre las acciones que actualmente se pueden realizar con nuestra GUI y declaraciones en este idioma dominio. Cambios GUI entonces significa que este único mapeo necesita ser actualizado, pero las pruebas pueden permanecer intactos, sin dejar de describir lo que hay que hacer en el nivel conceptual. Este mapeo toma la forma de un archivo externo en PyUseCase 3.0 y la próxima JUseCase 3,0, mientras que en las versiones anteriores que toma la forma de la instrumentación en el código de la aplicación.
Comprobar el comportamiento a través de los registros y texttest
Así que nuestra grabadora de casos de uso puede grabar y reproducir casos de uso para nosotros. Pero, ¿cómo podemos, comprobamos que lo que vemos en la pantalla es la correcta? La mayoría de las herramientas de la GUI hacen esto al permitir que el script de prueba que contiene "afirmaciones", que parecen un poco widget y comprueban que alguna propiedad de la misma es igual a un valor codificado. Esto crea aún más la dependencia del diseño GUI actual y no puede ser "grabada" de ninguna manera natural, pero tiene que ser programado en el después de los hechos. No "usecase" contendría naturalmente esta información: si lo hiciera se convertiría en un script de prueba.
Esta discusión no es en el sitio texttest para nada. Si sólo podemos obtener nuestra aplicación para producir un registro de lo que se ve la interfaz gráfica como podemos comprobar lo que hace al monitorear el contenido de ese registro mediante texttest. PyUseCase 3.0 lo hace por usted: genera un tipo de registro ASCII-arte de la apariencia GUI actual y monitorea los cambios a la misma. La aplicación puede complementarlo con su propio registro como desee. Con otras grabadoras de casos de uso de la aplicación necesita para construir su propio registro para este fin actualmente.
Sincronización de pruebas por la instrumentación de código
Casi todos los esfuerzos de pruebas GUI están plagados de problemas con asegurándose de que el script espera el tiempo suficiente antes de proceder cuando algo sucede en el fondo. Las soluciones van desde formas arcanas que esperar algún widget a tener una cierta apariencia (todavía más dependencias en GUI-mecánica) a los estados "sueño" generosamente esparcidos alrededor. ¿Qué falla cuando se carga el sistema y hacen que las pruebas se ejecuten mucho más lentamente de lo que lo haría. Cualquier persona sin el conocimiento íntimo del código está mal equipado para resolver este tipo de problemas, pero hacerlo es una parte vital de las pruebas de escritura.
Grabadores de casos de uso introducen el concepto de una "Solicitud de eventos". Esto es básicamente un poco de la instrumentación en el código que indica a la grabadora de casos de uso que algo ha sucedido que debe ser esperado, permitiendo así que la grabadora para grabar y reproducir espera, así como clics. Estos se describen en más detalle aquí.
macros de grabación, así como las pruebas
De alto nivel, fácilmente manipulables "casos de uso" son útiles para otras cosas además de la prueba. También son de gran utilidad para los usuarios del sistema que puede crear sus propias macros para las secuencias de acciones que realizan con frecuencia.
Estos son conocidos como "atajos GUI" aquí. Una grabadora de Uso caso normalmente permitirá una aplicación para solicitar una "barra de herramientas" de la misma que contiene controles para grabar y reproducir los que se pueden insertar en la interfaz gráfica de la aplicación si lo deseas. Además de permitir a los usuarios crear macros, también pueden ser utilizados para crear abstracciones nivel aún más alto para el "idioma de la prueba" descrito anteriormente, ayudando probadores en la realización de acciones repetidas para alcanzar un cierto pantalla para la prueba. Estos se describen en más detalle aquí.
Más información se puede encontrar en la página principal del proyecto

¿Cuál es nuevo en esta versión:.

• Soporte Muy básico para wxPython era agregado.
• También hay una serie de mejoras y correcciones de errores para PyGTK. Cabe destacar que gtk.Dialog.run es ahora compatible sin necesidad de cambios en el código fuente.
• Python 2.6 y PyGTK 2.12 o posterior se requiere ahora.
• La interfaz basada en la instrumentación legado ha sido retirado.

Requisitos

• Python
• PyGTK
• texttest