wpf - test - winappdriver
Experiencias con UI Automation y WPF (3)
Estamos desarrollando una aplicación basada en WPF bastante grande y nos gustaría incluir algunas pruebas de UI automatizadas en nuestro conjunto de pruebas (que ya contiene varias pruebas unitarias).
El marco de automatización de la interfaz de usuario de Microsoft suena en parte como un ajuste perfecto para el inicio programático y la interacción con la aplicación en una configuración de prueba. Sin embargo, me ha costado encontrar referencias sólidas para muestras y experiencias con la tecnología, los artículos y las pequeñas muestras disponibles en MSDN no son suficientes para convencerme de que es una opción sólida.
Entonces, ¿alguien tiene experiencias del mundo real utilizando el UI Automation Framework en su conjunto de pruebas? ¿Cuáles son las advertencias y las trampas? Cualquier práctica recomendada cuando se escriben scripts de prueba, ¿puede "grabar y reproducir" en un formato de secuencia de comandos, cuánto debería facilitar las pruebas desde la aplicación, cómo lo incorporó en la compilación automática? ¿Debemos mirar en otra dirección que no sea el marco de automatización de la interfaz de usuario?
Siéntase libre de publicar sus experiencias aquí o enlazar a algunas buenas referencias que podría haber perdido
Donde trabajo, acabamos de comenzar a evaluar algunas herramientas de prueba para nuestro sistema. Nos encontramos con una herramienta llamada white , que utiliza el marco de automatización de la interfaz de usuario. Tenga en cuenta que el blanco también tiene una función de grabación, aunque creo que tiene problemas de apariencia y aún está en desarrollo.
Lo que intentamos hacer fue configurarlos para que parecieran pruebas de unidad, es decir, [TestFixture] [Test] etc., luego pudimos ejecutarlos a través de nunit al mismo tiempo que las pruebas de unidad.
Hemos descubierto que puede ser difícil acceder a algunos de los componentes dentro de su ventana, pero no hemos tenido la oportunidad de investigar por qué.
Si no le importa pagar por el software, le recomendaría TestComplete .
Estoy en el medio de hacer la automatización de la interfaz de usuario de una aplicación WPF en el trabajo. Estoy usando White and IronRuby y funciona muy bien. He escrito cómo lo he hecho aquí: http://www.natontesting.com/2010/02/17/how-to-test-a-wpf-app-using-ironruby-and-white/
Inicialmente fuimos con el blanco, y luego nos alejamos de él. Intenta ser genérico y abstracto sobre la API de Win32, Winforms, aplicaciones de Java y la API de automatización de la interfaz de usuario de MS. La API de automatización de la interfaz de usuario de MS también está tratando de ser genérica y abstracta sobre la API win32 y las formas de ganancia y WPF, por lo que terminará en un escenario de "mínimo común denominador de más bajo común denominador".
El resultado de esto fue que la API de búsqueda de elementos blancos simplemente no era lo suficientemente flexible como para encontrar varios elementos de la interfaz de usuario que debíamos encontrar, y no mostraba lo suficiente de los elementos subyacentes del marco de automatización de la interfaz de usuario para que pudiéramos hacer algo útil con ella. .
Terminamos yendo con una especie de marco de cosecha propia; Usamos el marco de trabajo de UIA MS directamente, pero tenemos métodos de extensión y clases de ayuda para tratar los escenarios que no aborda. (Entrada teclado y ratón, principalmente).
Nota: nuestros scripts de prueba y nuestro marco de trabajo propio están usando IronRuby. La capacidad de Ruby para agregar métodos a las clases existentes y su sintaxis flexible (combinada con method_missing) son increíbles para este tipo de cosas.