pruebas de interfaz de usuario puede ser lenta, frágil y dolorosa de mantener, pero algunos errores sólo pueden ser atrapados en las pruebas de interfaz de usuario. La pregunta importante no es si vale la pena escribir pruebas de UI, sino cómo mantener sus pruebas de UI útiles, estables y fáciles de mantener.
Un error común es usar pruebas de IU como sustituto de otras pruebas. Teóricamente, puede probar muchas funcionalidades a través de pruebas de UI, pero hay muchos problemas con ese enfoque. Para empezar, algunas funciones pueden ser muy difíciles de probar directamente en la IU (especialmente en condiciones excepcionales). En segundo lugar, si una prueba falla, a menudo es difícil ver cuál es la fuente del problema. Finalmente, mientras más rutas de código pruebe en las pruebas de UI, más lentas serán las pruebas de UI. Si solo confía en las pruebas lentas, su productividad empeora, lo que aumenta la tentación de simplemente desactivar "temporalmente" las pruebas rotas.
Mi consejo es probar tanto como sea posible en pruebas unitarias y pruebas de integración, crear una buena separación entre su UI y su lógica de negocio, y usar sus pruebas UI para detectar y prevenir errores que no pueden ser probados en otros tipos de pruebas.
Si tiene muchas pruebas, considere crear varias suites. Creé una suite para pruebas de UI, una para pruebas de integración y una para pruebas unitarias. Las pruebas unitarias son muy rápidas, así que las ejecuto a medida que desarrollo mi código (a menudo a través de TDD). Estas son las pruebas que me ayudan a ser productivo.
Las pruebas de integración se ejecutan con menos frecuencia (tal vez después de haber implementado un poco de cambios). Las pruebas de IU que ejecuto cuando me estoy preparando para enviar un cambio (o cuando escribo más pruebas de IU, obviamente).
Un último consejo: considere escribir sus pruebas de UI con un Domain Specific Language. Esto hace que sea más fácil entender las pruebas (porque las lee como un conjunto de pasos de usuario y no como un conjunto de acciones de navegador de bajo nivel). También puede hacer que el código sea más fácil de mantener. Por ejemplo, en lugar de realizar todas las pruebas de las acciones del navegador paso a paso para iniciar sesión en el usuario, puede ver:
LoginPage loginPage = new LoginPage(selenium);
HomePage homePage = loginPage
.enterUserName(TestUsers.Alice.USER_NAME)
.enterPassword(TestUsers.Alice.PASSWORD)
.submit();
assertThat(homePage.getBreadcrumbs(), equalTo("Home"));