Self-healing locator (localizador autorreparable)

Un self-healing locator (localizador autorreparable) es un locator de test de UI respaldado por un mecanismo de recuperación. Cuando el locator principal no encuentra un elemento, por ejemplo porque cambió un id, la herramienta busca en la página el elemento que mejor coincide con lo que sabía del original (etiqueta, texto, atributos, posición, vecinos), lo usa y normalmente registra la “reparación” para que alguien actualice el test. El objetivo es reducir los fallos causados por cambios inofensivos en el marcado.

Cómo funciona en la práctica

La mayoría de las implementaciones siguen el mismo patrón:

1. En las ejecuciones que pasan, guardan una huella (fingerprint) de cada elemento que toca el test.
2. Cuando un locator falla, puntúan los elementos candidatos de la página frente a esa huella.
3. Si el mejor candidato supera un umbral, lo usan y registran la sustitución; si no, el test falla de forma normal.

Este tipo de reparación por similitud de atributos está consolidado: lo ofrecen herramientas comerciales, y Healenium es una opción de código abierto para Selenium. La reparación basada en LLM, en la que un modelo lee la página o el árbol de accesibilidad y propone un nuevo locator o un parche para el test, es más reciente. Los agentes de test de Playwright, introducidos en la versión 1.56, incluyen un healer que sugiere correcciones para los tests que fallan; trátalos como asistentes que proponen cambios para revisar, no como un piloto automático.

El riesgo real: reparar un bug auténtico

Una reparación asume que el cambio fue estético. A veces no lo fue:

• El botón “Submit” se eliminó por error y el healer hace clic en “Save draft” en su lugar.
• Un campo se reetiquetó de “Email” a “Username”, un cambio real de requisitos que el test debería haber señalado.
• Existen dos filas parecidas y el healer elige la equivocada, así que el test pasa contra los datos incorrectos.

En cada caso, un test que debería fallar se pone en verde. Reglas para que la reparación sea honesta:

• Informa de cada reparación y haz fallar la ejecución (o al menos márcala) en la puerta de release.
• Convierte las reparaciones en cambios de código. Acepta o rechaza el locator sugerido en la revisión; no dejes que la herramienta lo siga usando en silencio.
• Comprueba resultados, no solo interacciones, para que hacer clic en el elemento equivocado siga fallando en la siguiente aserción.

Arregla primero los locators

Gran parte de la fragilidad a la que apunta la autorreparación viene de selectores frágiles: cadenas largas de XPath, nombres de clase generados, rutas basadas en índices. Los locators orientados al usuario, como getByRole('button', { name: 'Submit' }) de Playwright, o los atributos data-testid estables eliminan la mayor parte de esa necesidad sin tener que adivinar nada.