Prueba de una aplicación WPF Gui-heavy

Question

Nosotros (mis colegas) tenemos un messy 12 y.o. aplicación madura que está basada en GUI, y el plan actual es agregar nuevos cuadros de diálogo & otra GUI en WPF, así como reemplazar algunos de los cuadros de diálogo anteriores en WPF también. Al mismo tiempo, deseamos poder probar esa automatización de GUI de Monster de forma sostenible. Algunos desafíos:

1. La aplicación es masiva.
2. Constantemente gana nuevas características.
3. Se está cambiando (correcciones de errores, parches).
4. Tiene un back-end y una capa intermedia. El estado de este puede salir de control si lo golpeas hasta la muerte.

Lo que queremos es:

• Algunos herramienta que puede automatizar las pruebas de WPF.
• descubrimiento automático de lo que son las entradas y las salidas del diálogo. Una antigua prueba aún debería funcionar si agrega una etiqueta que no hace nada. Sin embargo, debería fallar si elimina un campo de texto necesario. Sería muy bueno si el banco de pruebas fuera fácil de mantener, si funcionara y no se rompiera la mayor parte del tiempo.
• Cada nuevo cuadro de diálogo debe crearse teniendo en cuenta la capacidad de prueba.

En este punto no sé exactamente lo que quiero, así que lo voy marcando esto como un wiki de la comunidad. Si tienes que probar una gran aplicación basada en GUI, toca la campana (incluso si no está en WPF), entonces comparte tus experiencias buenas, malas y feas aquí.

Answer 1

OK, ¡su aplicación parece grande! Puedo compartir mis experiencias con una aplicación que diseñamos recientemente; era un GUI que hablaba de servicios web a un servidor que a su vez contactaba con múltiples bases de datos y otros servicios web.La base de clientes era de alrededor de 15,000 usuarios ... De cualquier manera, esto es mucho trabajo sin importar cómo se acerque; ¡Lo bueno es que te ayudará a no morderte las uñas cada vez que lo liberes!

MVVM

En general, yo también recomendaría el patrón MVVM y hacer tanto como sea posible sin pruebas de la interfaz gráfica de usuario. La prueba GUI es simplemente difícil Me gusta el artículo de Josh Smith en MSDN: "WPF Apps With The Model-View-ViewModel Design Pattern" (http://msdn.microsoft.com/en-us/magazine/dd419663.aspx)

Prueba de secuencias de comandos

El truco de esta aplicación es que teníamos mucho que probar, las tripas de que se mueve constantemente y había (curiosamente) no hay suficientes personas para realizar el trabajo de prueba para cada iteración.

Mi solución fue crear una herramienta de prueba personalizada que aprovechara las bibliotecas existentes. Teníamos un motor de script simple que leía un archivo y ejecutaba comandos. En efecto, desarrollamos un DSL (http://en.wikipedia.org/wiki/Domain-specific_language) para probar nuestra aplicación específica. El DSL incluía algunos comandos simples para indicar qué "ventana" estaba probando, cualquier señal de "configuración" específica y luego una serie de comandos seguidos por aserciones. Parecía algo como esto:

 
Test NewXyzItem 
Setup Clear_items 

Press Some_button 
Enter_text_into Name Bobby Joe 
(...) 
Press Save 

Assert_db_has_itemX SomeKey 

El formato de cada línea es

"command" "argument" [data] 

Los scripts van en grupos de directorios y las cargas "corredor de prueba" a ellos, los analiza y los ejecuta. La creación de registros e informes a medida que avanza es útil, me agregaron en el gancho para hacer capturas de pantalla, etc., que me resultó útil. Si está interesado en implementar algo como esto y desea una mano hágamelo saber.

Lo más práctico aquí es que podríamos hacer cambios globales a la estrategia de prueba.

Escribir los scripts se vuelve bastante simple, lo cual es importante porque terminas con muchos, muchos scripts. Los controles se descubren por su nombre, por lo que debe seguir una convención (por ejemplo, "Nombre" puede ser "NameTextBox" en el código, o "Guardar" podría ser "SaveButton").

En realidad, puede utilizar NUnit, etc. para ser su corredor de prueba también.

NOTA - Sólo ejecute las pruebas de forma interactiva, consiguiendo prueba de interfaz gráfica de usuario para trabajar con CI es difícil y problemático ...

datos y pruebas

Una cosa importante aquí es que la gestión de los datos fue una gran parte del problema de la prueba y no puede pasarse por alto. Nuestro "despliegue nuevo" también fue muy largo, pero algunas partes fueron externas y no teníamos control sobre la frescura de los datos. La forma en que manejamos la limpieza fue proporcionar ganchos a través de las secuencias de comandos que nos permitieron eliminar objetos fácilmente antes de las pruebas. No es óptimo, pero rara vez era un problema.

Bibliotecas

La biblioteca que puede resultar más útil en "White" (http://white.codeplex.com/) Se puede probar aplicaciones de Windows en general - es decir tanto en WPF y Windows Forms.Esencialmente se termina la codificación cosas como esta:

Button button = window.Get<Button>("SaveButton"); 
button.Click(); 

Si su aplicación hace asíncrono llama tendrá que subir con una estrategia para el corredor de prueba para saber cuando se termine la llamada asincrónica, tal vez, aunque la barra de estado o alguna cosa. Depende de cómo te enganches ...

De nuevo, mucho trabajo, pero vale la pena.

PK :-)

Answer 2

Una de las principales fortalezas de WPF es en realidad la capacidad de NO necesitar pruebas específicas de UI, en mi opinión. El uso de un enfoque M-V-VM le permitirá sacar la lógica del área UI/messy-GUI. Tener un ViewModel verificable por unidad (¡especialmente si está escribiendo nuevos cuadros de diálogo!) Le permite escribir pruebas unitarias que emulan el clic de su GUI.

Realmente reconsideraría lo que quiere lograr moviéndose a WPF y lo que quiere lograr con algún tipo de prueba automática de una GUI de WPF. Una vez que esto se haya establecido, consulte transitioning from WinForms to WPF si aún se ajusta a sus necesidades.

Answer 3

Como dice Jimmy Lyke, la mayoría de las pruebas deben centrarse en ViewModel. Esto consiste en escribir pruebas unitarias para ViewModel, básicamente enviando comandos y configurando y obteniendo propiedades.

Una vez hecho esto, el 95% de sus pruebas están fuera del camino. Si quieres dar un paso más y probar la vista más allá de las pruebas manuales de "tutoriales" que harías de todos modos, hay una serie de simples "controles de cordura" que puedes automatizar fácilmente para asegurarte de que no borraste accidentalmente un importante TextBox o renderizar un indicador visual invisible.

Cada una de las siguientes técnicas se puede automatizar utilizando un código de automatización simple que utiliza un enfoque "shotgun" ejecutando ciegamente el árbol visual y asumiendo nada sobre la estructura de la interfaz de usuario real.

• para verificar que todos los datos de modelo de vista está obligado, se encuentran todas las representaciones visuales y Freezables (utilizando el árbol visual) y comprobar cada propiedad con destino a camino de la unión de su BindingExpression.

• Para verificar que todos los datos de ViewModel se muestran de alguna manera, varíe los datos de ViewModel utilizando un script y después de cada cambio utilice RenderTargetBitmap para capturar la UI y compararla antes de que los datos cambien para asegurarse de que la UI haya cambiado.

• Para verificar que los valores de propiedad se estén actualizando correctamente, encuentre todos los visuales y Freezables y escanea y registra todas las propiedades enlazadas, luego haga que ViewModel cambie, vuelva a explorar y busque el cambio esperado a cualquier propiedad del tipo dado (Para verificarlo, puede usar la técnica de comparación de mapas de bits en el Visual afectado.)

• Para verificar que todos los comandos estén accesibles, establezca un estado conocido de ViewModel y luego ejecute cada comando vinculado a un botón visible para ver si alguno de ellos desencadena el ICommand o actualiza el estado de ViewModel.

• Para verificar que una propiedad de ViewModel sea realmente editable por el usuario, cambie el contenido o la selección de todos los TextBox, ComboBox, ListBox visibles para ver si alguno de ellos afecta la propiedad.

• Para tener la oportunidad de comprobar cualquier cambio que afecte a la IU, mantenga una base de datos que contenga instantáneas de mapa de bits de cada vista en varios estados de ViewModel en un conjunto de tamaños de ventana diferentes. Cuando se genera una nueva versión de la aplicación, ejecute el mismo sistema de instantáneas y compárelo con los mapas de bits anteriores. Si algo ha cambiado en absoluto, genere una tarea manual para el personal de control de calidad para comparar visualmente los mapas de bits antiguos y nuevos para ver si algo importante ha cambiado.

Otra automatización de prueba es posible en la vista, pero lo anterior le dará un comienzo.

Una vez más debo señalar que lo mejor es centrarse en probar a fondo el modelo de vista. Los errores en la vista en sí son bastante raros, generalmente se detectan rápidamente y generalmente son triviales de arreglar. Pero una vez que las pruebas de ViewModel son exhaustivas, tiene sentido realizar una cierta automatización de la prueba de visualización.

Answer 4

Usted tienen una aplicación muy grande. Supongo que tiene mucha lógica envuelta con la capa de presentación y nunca tendrá el tiempo de refactorizar la bestia para separar la vista del resto de la lógica.

No tienes un montón de opciones aquí, pero:

1. Refactor el código a medida que avanza. Estas pueden ser pequeñas extracciones de métodos para que pueda probar la unidad o cambiar a un modelo adecuado.
2. Utilice una o más de la variedad de Windows GUI testing tools. Tenga en cuenta que si planea una gran cantidad de diseños y/o cambios de control, postergue esto el mayor tiempo posible. Las herramientas en este artículo usarán posicionamiento absoluto de acciones, control vinculado (a veces por IDs internos) o una mezcla de ambos. Dado que por lo general tienen que ser entrenados sin usar código (dirigido a probadores de CC, no a programadores), sus pruebas dejarán de funcionar después del cambio.
3. Invierta en probadores humanos. Si bien no es una buena opción, mejora la calidad final y comienza a hacer que la administración piense más sobre los costos de la refacturación de la aplicación.

Answer 5

Para probar WPF apps de que hay algunas cosas que hemos tenido éxito con:

1. PowerShell
2. TestPlant

y posiblemente sería el nuevo VSTS 2010 features, aunque no los hemos probado