Los tres fallos en tiempo de ejecución que el testing de aplicaciones web tiene que cubrir
Estado residual
Un modal se cierra y deja el scroll bloqueado. Un filtro persiste donde no tiene sentido.
Solo aparece en la segunda interacción, así que una reproducción desde cero nunca lo encuentra.
Render antes que los datos
La página se pinta, el fetch se resuelve, nada se vuelve a renderizar.
Suele ser intermitente, y por eso sobrevive a la revisión.
El segundo usuario
Suposiciones de propiedad y visibilidad creadas desde la sesión de quien desarrolla.
Funciona a la perfección para quienes lo construyeron.
La comprobación que detecta la mayoría
Haz la acción dos veces, como dos usuarios distintos, con una recarga en medio. Ese único patrón cubre las tres categorías, y es justo lo que el testing manual se salta porque el primer intento funcionó.
Qué verificar
Algo que una recarga confirmaría. Un mensaje de éxito no demuestra que algo se haya guardado. Vuelve a consultarlo.
La ausencia de lo que no debería estar. Después de borrar, la fila ya no está. Después de cerrar sesión, los datos no se ven.
El comportamiento para otra persona. La segunda cuenta no puede ver los registros de la primera.
Dónde encaja el desarrollo local
El trabajo en aplicaciones web ocurre en localhost mucho antes de que se despliegue nada, y una comprobación que solo funciona contra una URL pública llega demasiado tarde para cambiar lo que construyes. La CLI puede crear un túnel hacia una aplicación que corre en tu propia máquina para las ejecuciones de frontend, así que la comprobación está disponible mientras sigues trabajando. Encontrarás los detalles en el repositorio de la CLI.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El dashboard cubre lo mismo para quien no quiera una instalación local.
La prueba de las dos pestañas
Hay una comprobación manual que vale la pena hacer antes de cualquier release y que encuentra más de lo que cuesta, y casi nadie la hace: abre la aplicación en dos pestañas.
Haz algo en la primera y luego mira la segunda. La mayoría de las aplicaciones web se comportan mal aquí de alguna forma, y ese mal comportamiento es informativo. Una lista que no se actualiza suele estar bien. Una acción obsoleta que se completa con éxito y sobrescribe datos más nuevos es un bug real. Una sesión que cierra la sesión de una pestaña cuando la otra renueva un token es un bug real. Una actualización optimista que nunca se reconcilia es un bug real.
Toma dos minutos, no necesita ninguna herramienta y ejercita justo la costura donde el estado del servidor, el estado del navegador y la expectativa del usuario no coinciden. Si solo incorporas un hábito de esta página, que sea ese.
Hazlo continuo
Los fallos en tiempo de ejecución son justo los que reaparecen, porque las condiciones que los producen son fáciles de recrear sin querer.
La GitHub App es un webhook que configuras en el dashboard de TestSprite. Escucha el evento de despliegue que tu pipeline ya genera, así que no cambia nada en tu repositorio.
GitHub Actions pone el paso dentro de tu propio workflow, configurado desde la terminal.
Cómo TestSprite ejercita la aplicación en ejecución
Abre la aplicación desplegada y la usa como lo haría una persona, que es la única manera de ver el estado residual, el render antes que los datos y el comportamiento del segundo usuario. Los casos se describen en lenguaje sencillo y se generan a partir de tu producto, y verifican cosas que una recarga confirmaría en lugar de un mensaje que pintó el cliente.
La comprobación del segundo usuario es un caso de primer nivel y no un ejercicio de configuración, y eso importa porque las suposiciones sobre permisos son el fallo con más probabilidades de llegar a un cliente y menos probabilidades de que lo note quien construyó la funcionalidad.
Después, las comprobaciones siguen ejecutándose en cada cambio, así que los desacuerdos entre los tres estados que una vez provocaron un bug no pueden reaparecer en silencio después de fusionar la rama.
¿Por qué no aparecen en la revisión de código?
Porque son propiedades de una interacción entre el estado del servidor, el estado del navegador y el historial. Un diff no muestra nada de eso.
¿Podemos probar esto con pruebas unitarias?
En parte, con muchos mocks, y esos mocks codifican las mismas suposiciones que el código. Ejecutar lo real es lo que desempata.
¿Cómo probamos al segundo usuario de forma fiable?
Mantén una segunda cuenta por entorno y ejecuta el mismo flujo con ambas. Es la comprobación más barata y de mayor rendimiento en el testing de aplicaciones web.
¿Y los navegadores móviles?
Las diferencias de viewport sacan a la luz otro conjunto de problemas de layout e interacción. Vale la pena cubrir los flujos principales en tamaño móvil si tienes tráfico móvil.
¿Cuánto de esto se puede ejecutar en local?
Las ejecuciones de frontend pueden llegar a una aplicación en tu máquina a través de un túnel. Los destinos de backend que no son accesibles siguen necesitando un entorno expuesto.
Hazlo dos veces, como dos usuarios, con una recarga.
El testing de aplicaciones web tiene que cubrir el estado residual, el render antes que los datos y el comportamiento del segundo usuario, y nada de eso se ve en el código fuente. Verifica lo que una recarga confirma, comprueba la ausencia de lo que debería haber desaparecido y ejecuta el mismo flujo como otra persona.