En Madrid hay unos pequeños puntos de préstamo de libros dentro de estaciones de metro: el Bibliometro. De los 12 que había, 6 cerraron; quedan 6 abiertos. El problema es simple: el catálogo oficial de la Comunidad de Madrid no te lo pone fácil.
Hice https://www.librometro.es: consulta el catálogo público y te dice en cuál de los 6 módulos está el ejemplar y, si está prestado, cuándo vuelve. Sin anuncios, sin cuentas, sin features inutiles. El objetivo es que cualquier persona (incluida la gente que necesita accesibilidad visual o talkback) pueda siempre obtener esa informacion en menos de 3 interacciones.
Pero eso fue la parte fácil. La parte interesante fue otra: ¿cómo sé que esto sigue funcionando dentro de tres meses?
El problema de testear una UI que cambia
Escribir tests para la interfaz es horrible, un infierno en vida. "El botón dice Buscar". Cambias el copy y el test se rompe. El proceso es lento y desesperante. O peor aun, tienes un semáforo de adorno. Si no afirmas nada, en cambio, nada te avisa cuando una pantalla se rompe.
Lo que hice fue no escribir un oráculo. Enumeré los recorridos reales de la app por funcionalidad: el tablero vacío, la búsqueda con resultado, la búsqueda sin resultado, el panel de una estación, la lista de un autor... Cada uno monta esa pantalla y escribe lo que observa como hechos en texto: qué texto es visible, dónde está el foco, si una sección aparece o no.
Después guardo ese presente como un "pasado" (un baseline) y la siguiente ejecución compara contra ese pasado. El sistema no juzga: reporta qué cambió, y yo decido. Nunca rompe el build.
Un ejemplo concreto
La app tiene dos árboles de presentación (móvil y escritorio) que comparten datos y copy pero se dibujan distinto. En móvil, un enlace compartido con "?q=...&estacion=..." abría directamente el panel de esa estación. En escritorio, no: ignoraba el parámetro. El enlace funcionaba a medias según el ancho de pantalla.
Es el tipo de bug que no ves mirando: el escritorio "funcionaba", solo que no hacía lo que prometía el enlace.
Añadí un recorrido nuevo que carga esa URL compartida y anota lo que ve. El "pasado" quedó guardado así:
── Enlace compartido a una estación ──
Panel from shared link: empty
Selected chip: absent
Fired events: board_viewed
Arreglé el escritorio y volví a pasar el sensor:
── Enlace compartido a una estación ──
Panel from shared link: filled
Selected chip: sierra-de-guadalupe
Fired events: board_viewed, sheet_opened
Exactamente el cambio que quería, y nada más. Eso es lo que me gusta del enfoque. No me dice "correcto", me dice qué cambió desde la última vez que lo miré.
Como medir la herramienta
Un sistema así solo vale si no miente. Y los sensores mienten. Así que empecé a llevar un registro de cuándo mi propia herramienta se equivocaba. Todo error se registra, tanto falsos positivos como falsos negativos.
Dos ejemplos reales de esa lista:
Un diff de píxeles marcó una captura porque la animación del panel estaba a medio camino. No era una regresión, era el momento de la foto. Se arregló congelando las animaciones antes de capturar. El sensor de "texto visible" no veía un párrafo que mezclaba texto con un enlace dentro. El texto se renderizaba bien, pero el sensor lo omitía en silencio.
Un selector que deja de coincidir registra null. Si el baseline también tenía null, no hay diff: la pantalla puede romperse y el sensor no dice nada. Lo arreglé con un sensor explícito (absent) distinto de "no consultado", y haciendo que un valor que pasa a ausente nunca se acepte en silencio.
Si has montado algo parecido —verificación sin aserciones, snapshots, grabaciones de estado— me interesa mucho cómo lo resuelves. Y si ves un agujero en el enfoque, mejor todavía.
