.net - tutorial - Prueba de una aplicación WPF Gui-heavy

wpf vs windows forms

Question

Nosotros (mis colegas) tenemos una aplicación madura desordenada de 12 años que está basada en GUI, y el plan actual es agregar nuevos diálogos y otra GUI en WPF, así como reemplazar algunos de los diálogos más antiguos 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 todo (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:

• Alguna herramienta que puede automatizar las pruebas de WPF.
• autodescubrimiento de cuáles 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 diálogo debe crearse teniendo en cuenta la capacidad de prueba.

En este punto, no sé exactamente qué es lo que quiero, así que estoy marcando esto como una wiki comunitaria. 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

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 que lo haya hecho, el 95% de sus pruebas estará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 de "escopeta" ejecutando a ciegas el árbol visual y sin asumir nada sobre la estructura de la interfaz de usuario real.

• Para verificar que todos los datos de ViewModel están vinculados, encuentre todos los visuales y Freezables (usando el árbol visual) y verifique cada propiedad enlazada para su ruta de enlace de 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, escanea y registra todas las propiedades enlazadas en ellos, 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 sean accesibles, establezca un estado conocido de ViewModel y luego ejecute cada comando vinculado a un botón que esté visible para ver si alguno de ellos dispara 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 cada TextBox visible, ComboBox, ListBox para ver si alguno de ellos afecta la propiedad.

• Para tener la oportunidad de verificar cualquier cambio que afecte a la IU, mantenga una base de datos que contenga instantáneas de mapas 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.

De nuevo, debo señalar que lo mejor es concentrarse en probar exhaustivamente ViewModel. 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 2

OK, tu aplicación suena 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, también recomendaría el patrón MVVM y haré tantas pruebas como sea posible sin la GUI. La prueba GUI es simplemente difícil Me gusta el artículo de Josh Smith en MSDN: " Aplicaciones WPF con el patrón de diseño Model-View-ViewModel " ( http://msdn.microsoft.com/en-us/magazine/dd419663.aspx )

Prueba de secuencias de comandos

El truco de esta aplicación fue que teníamos mucho que probar, las agallas se movían constantemente y había (por extraño que parezca) poca gente para realizar el trabajo de prueba en 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 ( DSL ) 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. Se veí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 entran en grupos de directorios y el "corredor de prueba" los carga, 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ás interesado en implementar algo como esto y quieres una mano házmelo saber .

Lo útil aquí fue que podríamos hacer cambios generales 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 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: solo ejecutar las pruebas de forma interactiva, hacer que la prueba GUI funcione con CI es difícil y problemática ...

Datos y pruebas

Una cosa importante aquí es que la administración de datos fue una gran parte del problema de 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 encontrar más útil en " White " ( White ) Puede probar aplicaciones de Windows en general, es decir, tanto WPF como WinForms. Esencialmente terminas codificando cosas como esta:

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

Si su aplicación realiza llamadas asíncronas, deberá idear una estrategia para que el corredor de pruebas sepa cuándo finalizó la llamada asincrónica, tal vez mediante la barra de estado o algo así. Depende de cómo te enganches ...

Nuevamente, mucho trabajo, pero vale la pena.

PK :-)

Answer 3

Para probar las aplicaciones WPF hay algunas cosas con las que hemos tenido éxito:

1. PowerShell
2. TestPlant

y posiblemente serían las nuevas características de VSTS 2010 , aunque no las hemos probado

Answer 4

Tienes 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 muchas opciones aquí, pero:

1. Refactorice 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. Use una o más de las herramientas de prueba de la GUI de Windows . 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

Una de las principales fortalezas de WPF es la capacidad de NO necesitar pruebas específicas de IU, en mi opinión. El uso de un enfoque MV-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 al pasar 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, analice la transición de WinForms a WPF si todavía se ajusta a sus necesidades.