¿Deben los desarrolladores web diseñar conscientemente sus aplicaciones para pruebas automatizadas?

En general, diría que sí. Las pruebas automatizadas de IU se mejoran enormemente si utiliza las siguientes pautas:

• Use ID estables para las cosas que no cambian. Si la cuadrícula de pedidos es siempre la misma ID (“grdOrders”), el XPATH resultante es más estable para la automatización.
• No utilice identificadores basados ​​en datos transitorios, como sesiones de usuario
• Utilice los atributos de accesibilidad ARIA, buenos para humanos, muy buenos para humanos con discapacidad visual, mejores para automatización
• Intente usar CSS para diseñar y evitar demasiada estructura de andamios innecesaria en el propio HTML (por ejemplo, ¡100 DIV anidados!)

Sí. Los desarrolladores deben diseñar código considerando factores importantes:

1. Legibilidad: más fácil de analizar y depurar
2. Escalabilidad: más fácil de expandir

Los códigos que son legibles y escalables son más adecuados para la automatización.

Sin embargo, no todos los códigos deben automatizarse a menos que el software no cambie en absoluto. En la mayoría de los casos, hay cambios debido a mejoras y correcciones. Los scripts de prueba de automatización solo deben cubrir los procesos principales del sistema, es decir, las partes que no cambian mucho independientemente del cambio. Aplicando el Principio de Pareto, el 20% superior de la entrada contribuye al 80% de la salida.

Más allá de cierto punto, se encontrará con la ley de rendimientos decrecientes , llegando finalmente a un punto en el que solo agrega una capa adicional de programación para cada cambio de código, pero el beneficio adicional será solo marginal y no agregará mucho valor comercial. Los scripts de prueba de automatización también son códigos y deben probarse al igual que el producto real.