La mejor práctica para las pruebas de automatización de la interfaz de usuario es hacer lo menos posible. Las interfaces de usuario cambian con frecuencia, lo que significa que constantemente tiene que actualizar su automatización. En general, es preferible estructurar el código del producto de una manera que permita realizar pruebas automatizadas sin automatización de la interfaz de usuario.
Dicho esto, no siempre puedes deshacerte de UI Automation. Menciona Office, así que supongo que está codificando para Windows y está usando .Net. Hago bastante en mi trabajo actual. Estas son algunas de las cosas que he aprendido.
1) Mire las bibliotecas de UIAutomation que se introdujeron en .Net 3.0. Proporcionan una biblioteca extensa y bastante simple de usar para la automatización. (http://msdn.microsoft.com/en-us/library/ms753107.aspx)
2) Descargue UISpy (http://msdn.microsoft.com/en-us/library/ms727247.aspx)
3) Haga que las IU de su producto sean automatizables.
3a) Si se trata de WPF, ponga AutomationIDs en todo.
3b) Intente crear un control distintivo y nombres de clase de ventana (nombres de clase de UI, no nombre de clase de código fuente). Si no sabe a qué me refiero, cargue UI Spy y comience a mirar las ventanas. Observe cuántas ventanas en diferentes aplicaciones tienen un nombre de clase de # 32770. Este es el nombre de la clase para un cuadro de diálogo de Windows. Cualquier ventana que extienda el diálogo y no establezca su propio nombre, por defecto es esto. Esto causa todo tipo de dolor desde el punto de vista de la automatización de la interfaz de usuario.
4) Evite las declaraciones Thread.Sleep (). Intente usar Waiters (consulte los documentos de UIAutomation) en su lugar.
5) NUNCA mezcle el código de prueba con el código de automatización de la interfaz de usuario. Cree bibliotecas separadas para realizar la automatización de la interfaz de usuario. Llame a estas bibliotecas desde sus pruebas. Cuando la interfaz de usuario cambia, esto hará que sea mucho más fácil actualizar la automatización.
6) Siempre registre un oyente para un evento de IU antes de realizar la acción que provocaría que el evento se disparara. En la práctica, esto significa que trabajará con hilos.
6a) Ejemplo: no empiece a esperar un evento de Ventana abierta después de hacer clic en un botón para abrir la ventana. La ventana puede abrirse antes de que el camarero se registre y nunca obtener el evento.
7) Nunca asumas que la ventana que acaba de abrir es la que deseas. Se pueden abrir inesperadamente todo tipo de ventanas en Windows.
Podría seguir más, pero esto se está haciendo un poco largo.