¿Cómo evito que las pruebas E2E se rompan con cada cambio de la interfaz?

Las pruebas E2E se rompen tras un cambio de la interfaz porque encuentran los elementos por una clase, un id, un texto o una posición, y eso es justo lo que cambia un rediseño. Nexus Studio, de Verdict System LLC, lo resuelve en tres pasos: propone un localizador nuevo y pregunta antes de cambiar la prueba, marca como AUTO_RECOVER una ejecución que salvó un selector reparado en lugar de darla por un pase limpio, y lista los localizadores débiles para que los corrijas antes.

Por el equipo de Nexus Studio, Verdict System LLC. 7 de octubre de 2026.

¿Por qué fallan las pruebas de Playwright y Selenium cuando cambia la interfaz?

Un localizador es la dirección que usa una prueba para encontrar un elemento. Cuando esa dirección depende de algo que no forma parte de lo que hace el elemento, como una clase generada por el build, una posición en la página o la redacción de una etiqueta, un cambio en la página vuelve incorrecta la dirección y la prueba falla en esa línea, aunque la aplicación siga funcionando.

El costo no es el fallo aislado. Es el tiempo que un equipo dedica a leer ejecuciones en rojo, encontrar la línea, encontrar un localizador nuevo y editar el archivo, otra vez tras cada release.

¿Qué problema tiene la autorreparación que arregla las pruebas en silencio?

Una herramienta que cambia un localizador roto sin avisar a nadie mantiene la suite en verde, pero también oculta el cambio. La prueba ahora hace clic en algo que su autor no eligió y nadie lo revisó. Si la nueva coincidencia es el elemento equivocado, la prueba puede pasar mientras verifica otra cosa.

Nexus Studio sigue la regla contraria: nada se repara a tus espaldas.

¿Cómo repara Nexus Studio un localizador roto?

• Con la autorreparación en su ajuste por defecto, Suggest, cuando una prueba falla el Studio abre un navegador en segundo plano, repite la prueba hasta la línea que falló y lee la página. Los candidatos están listos cuando abres el fallo. No usa IA y la prueba sigue en rojo.
• Desde el margen de la línea fallida, la Repair line te deja volver a grabar solo ese paso, o cambiar el selector por uno de los candidatos. Los candidatos van del más fuerte al más débil, y XPath va al final.
• El cambio llega al editor sin guardar. Guardarlo es tu aprobación.
• También puedes preguntarle a tu IA cuál candidato elegir. Puede reordenar los candidatos, nunca añadir uno, y la versión anterior del archivo queda en su línea de tiempo.

¿Qué significa que una prueba pase con un selector reparado?

El veredicto es AUTO_RECOVER: la ejecución pasó, pero la autorreparación tuvo que reemplazar un selector de esa prueba. Nunca se reporta como SECURE, el pase limpio. El localizador que escribió el autor ya no sirve, y el próximo cambio de la página rompe la suite de verdad, así que la reserva sigue visible en el informe y en History hasta que alguien corrija el selector original.

AUTO_RECOVER es uno de los siete veredictos de pase, así que un trabajo de CI termina con código 0. La reserva se ve en el informe, no como un build roto. El orden completo de las comprobaciones está en Cómo decide Nexus Studio 14 veredictos de prueba.

¿Cómo encuentro los selectores débiles antes de que se rompan?

• Locator health lista los localizadores débiles de la prueba abierta, con la línea de cada uno, y los repara por el mismo diálogo que la Repair line.
• Los Selector Maps escanean una página sin IA, califican cada selector HIGH, MEDIUM o LOW, y guardan el mapa en tu disco.
• El Vet, las siete comprobaciones que debe pasar toda prueba escrita por IA, incluye la regla de que la prueba no tenga localizadores frágiles.

¿Qué localizadores elige el Recorder?

El Nexus Recorder escribe lo que haces clic como código de prueba, sin IA de por medio. Puede usar un atributo de test id: si eliges data-testid en una grabación en JavaScript, lee data-testid y también data-qa. Las grabaciones en Python y Selenium conservan el único nombre de atributo de su runner. Los selectores escritos con estos atributos se califican como robustos, mientras que una clase generada por el build, una cadena CSS profunda y un nombre de etiqueta solo se califican como frágiles.

¿La prueba sigue siendo un archivo estándar de Playwright o Selenium?

Sí. Toda prueba que el Studio escribe o importa es código de un framework que tu equipo ya conoce: un archivo de Playwright Test, o Selenium en JavaScript o Python. Una reparación edita una línea de ese archivo, así que no hay un formato propietario del que migrar si dejas de usar el Studio.

Límites

• La autorreparación en modo Suggest no arregla nada por sí sola. Una persona sigue aprobando cada reparación, así que un cambio grande de interfaz sigue requiriendo tiempo de revisión.
• La lectura automática tras un fallo necesita memoria libre en la máquina. Si no hay suficiente, no arranca, y aun así puedes pedir los candidatos a mano.
• Locator health lee el archivo línea por línea, así que un localizador repartido en varias líneas no se detecta.
• Un localizador débil que aún funciona no es un fallo. Locator health te avisa, pero nada te obliga a cambiarlo.

¿Dónde puedo verlo funcionando?

El recorrido por el Studio muestra la Repair line y Locator health en pantalla, la guía de veredictos explica AUTO_RECOVER junto a los otros 13 veredictos, y la prueba de 30 días ejecuta el mismo motor sobre tus propias pruebas.