Probar componentes

Su formulario de registro está cubierto por catorce pruebas, todas en verde. El mes pasado, un desarrollador sustituyó <div class="erreur"> por un componente <Alerte> que aplica clases utilitarias generadas. Las catorce pruebas, que buscaban .erreur con querySelector, pasaron a rojo en bloque aunque el producto funcionaba perfectamente. Dos horas después estaban arregladas; y, la semana siguiente, se coló un bug real: el mensaje de error se mostraba correctamente, pero sin vínculo con el campo afectado, por lo que resultaba invisible para un lector de pantalla. Ninguna prueba lo detectó.

Los dos fallos tienen la misma causa. Consultar el DOM por clase CSS prueba la estructura interna del renderizado, no lo que percibe el usuario. La estructura cambia constantemente sin que el comportamiento se mueva, lo que produce falsos positivos; y permanece idéntica cuando la accesibilidad se degrada, lo que produce falsos negativos. La corrección es mecánica: busque sus elementos por su rol accesible y su nombre accesible, exactamente como lo hace un lector de pantalla o un usuario que navega con el teclado. Sus pruebas se vuelven así insensibles a los rediseños de estilo y sensibles a las regresiones que realmente importan.