¿Cómo estructuras una base de código de automatización de interfaz para que no se vuelva imposible de mantener?

Separa las capas. Los objetos de página o de componente encapsulan los selectores y las interacciones de bajo nivel; una capa de flujos los compone en acciones de negocio como iniciar sesión o completar la compra; los tests contienen solo intención y comprobaciones. Guarda los selectores en un único sitio, prefiere identificadores de test dedicados antes que rutas CSS frágiles, y mantén las comprobaciones fuera de los objetos de página para que los fallos apunten a la capa correcta.

Trato el código de test como código de producción, así que se aplican las mismas reglas: nada duplicado, capas claras, nombres con sentido. Abajo tengo objetos de página o de componente que son dueños de los selectores y de la mecánica de interactuar con esa parte de la interfaz. Encima va una capa de flujos para las acciones a nivel de negocio, del tipo inicia sesión como usuario con este rol, o añade un artículo y completa la compra, porque esas secuencias se reutilizan constantemente y no quieres tenerlas copiadas en cuarenta tests. Los tests en sí se leen entonces como el requisito, sobre todo llamadas a métodos y comprobaciones. Mantengo las comprobaciones fuera de los objetos de página, porque cuando un objeto de página comprueba, un fallo te dice que una página está descontenta en lugar de qué comportamiento se rompió. Sobre los selectores, insisto mucho en atributos de test dedicados acordados con los desarrolladores, porque perseguir rutas CSS que cambian cada vez que alguien reestiliza un componente es el principal motivo por el que estas suites se acaban abandonando. Y hago la preparación por la API siempre que puedo: si un test va de la compra, crear la cuenta y el carrito por HTTP es más rápido y muchísimo menos inestable que recorrer doce pantallas para llegar ahí.