Luchando contra la inestabilidad de las pruebas con máquinas del tiempo

Gracias. Muchas gracias. La respuesta a cómo lo manejo con 4Kids es magia, y esa magia es mi esposa.

Muy bien. Entonces, el tema es luchar contra la inestabilidad de las pruebas con máquinas del tiempo. Así que tengo una pregunta para ustedes, para empezar. ¿Les gustaría viajar en el tiempo? Levanten sus manos. ¿Quién quisiera viajar en el tiempo? Muy bien. ¿Qué les gustaría hacer si pudieran viajar en el tiempo? ¿Cambiar el proyecto en el que están trabajando? Esa es una respuesta muy de desarrollo de software. ¿Quién más? ¿Tenemos a alguien más que haya levantado la mano? Pueden gritarlo. Comprar algunos Bitcoins. Comprar algunos Bitcoins, muy bien. Esas son grandes respuestas.

Para mí, en realidad, iría a mi propia vida y aplicaría el conocimiento que tengo hoy. Así que sí, tal vez comprar algunos Bitcoins o, ya sabes, como cuando estoy discutiendo con mi hermano y tengo una respuesta ingeniosa, pero como tres meses después, querría usar eso, ya sabes, así que ahí lo tienen. El punto que estoy tratando de hacer, es que aprendemos del pasado. Ahora estamos en TestJS Summit y podrías preguntar, como, ¿qué tiene que ver este viaje en el tiempo con algo? Es que aprendemos del pasado. Si podemos viajar en el tiempo y aplicar el conocimiento que tenemos hoy, podemos hacerlo mejor. Muchas pruebas son en realidad el proceso de aprender del pasado. Por ejemplo, si escribes un informe de error, documentas las cosas que sucedieron, intentas mirar al pasado, y así puedes intentar arreglarlas. Con la automatización de pruebas, utilizamos todo tipo de datos diferentes y vemos rastros de la ejecución de la prueba. Nuevamente, miramos al pasado y aplicamos ese conocimiento. Si estás haciendo SRE, probablemente hayas realizado una reunión post-mortem después de un incidente. Y todo eso es básicamente aprender del pasado.

Muy bien, ahora la pregunta. ¿Cómo aprender del pasado? Si lo piensas, solo tenemos un par de opciones. Podemos usar nuestras propias memorias, intentar recordar lo que ha sucedido. Podemos hablar con alguien que presenció algo de interés. Podemos intentarlo de nuevo. Podemos intentar recrear el pasado.

O podríamos usar una máquina del tiempo. Y de hecho tenemos máquinas del tiempo y voy a hablar de ellas. Y todas estas formas de viajar al pasado son buenas, pero tienen algunos defectos.

Entonces, vayamos a la primera, usando tu memoria. Entonces, si estás escribiendo un informe de error, recientemente pregunté en LinkedIn, ¿cómo escribes un informe de error? ¿Y estas son las diferentes respuestas que llegaron, qué debería hacer el informe de error? Y es mucho. Y ni siquiera he incluido todo. Son descripciones, pasos para reproducir, capturas de pantalla, videos, comportamiento deseado, etcétera, etcétera. El mayor problema es que incluso con toda esta información, aún podría no ser suficiente.

Lo que me lleva a la otra cosa, hablar con alguien. Especialmente esto sucede en un equipo donde la testing y la corrección del error o la reproducción y la corrección del error se distribuyen entre muchas personas diferentes o más personas. Y hay un puente de comunicación que necesitamos crear. Y la comunicación es difícil. No es una tarea fácil. E incluso en la vida real, si quieres hablar con alguien, y más aún si quieres intentar transmitir información compleja.

Esto a menudo conduce a un problema que muchos de nosotros ya hemos tenido. No se pudo replicar, moviendo al backlog. ¿Alguien ha experimentado esto? ¿Sí? ¿Okay? Entonces no soy solo yo. Y puede ser tan molesto para todas las partes involucradas. A menudo, puedes tener personas increíblemente inteligentes, y aún así sucedería. Como un par de manos levantadas aquí. Todos ustedes son personas inteligentes y les ha sucedido a ustedes. Y sin culpa tuya, podrías carecer de información, podrías carecer de comunicación clara, podrías carecer de conocimientos técnicos. Y de nuevo, sin culpa tuya, siempre hay algo que puede interponerse en el camino de encontrar el problema y luego solucionar el problema y aprender del pasado. Aprender lo que sucedió.

Entonces, de nuevo, hablar con alguien en general es genial. Pero cuando quieres aprender del pasado. Pero también tiene algunos defectos. Entonces, pasemos al siguiente punto.

Intentarlo de nuevo. Esa es otra forma de cómo podemos aprender del pasado. AKA depuración. AKA intentar recrear el pasado. Ahora, todos hemos hecho depuración. Sabemos lo difícil que puede ser. Puedes usar el desarrollo local, puedes usar el depurador o las declaraciones de impresión.

Por cierto, ¿declaraciones de impresión o depurador? ¿Declaraciones de impresión? Levanta la mano. Okay. Bien. ¿Depurador? Okay. ¡Oh! Tenemos algunas personas elegantes. Muy bien. Sí. Todo y todo lo que haces con la esperanza de recrear el problema, intentar replicar, tal vez intentas una y otra vez en un contexto de prueba automation, podría ser volver a ejecutar la prueba de nuevo. Walmart tuvo una buena demostración de cómo puedes quemar la prueba e intentar de nuevo para reproducir algo así como una prueba inestable.

Y esto me lleva a, como, la última cosa de cómo podemos aprender del pasado, y eso es las máquinas del tiempo. Personalmente, encuentro las máquinas del tiempo las más emocionantes, especialmente en el contexto de la prueba automation. Las máquinas del tiempo pueden revelar sutilezas que de otra manera estarían ocultas para nosotros. Por ejemplo, las máquinas del tiempo pueden mostrarnos instantáneas tontas. Esta es una captura de pantalla de una prueba de Cypress que está fallando. Tenemos una aplicación de demostración de comercio electrónico donde queremos comprar esta zapatilla elegante. Y la prueba básicamente hacemos clic en un botón, añadir al carrito, y queremos ver un mensaje, como añadido con éxito al carrito. Ahora, esta prueba está fallando, pero podemos usar la máquina del tiempo, podemos viajar atrás en el tiempo y mirar el evento de clic. Y lo que podemos ver en este corto video es que cuando hicimos clic en el botón, había este contador que muestra el número cero. Así que en realidad estábamos tratando de comprar cero zapatillas. Y este tipo de información, esta instantánea del punto donde se hizo el clic, puede ser realmente, realmente útil. Así que esta es la prueba. Y ahora podemos cambiar esa prueba, usar esa información del viaje en el tiempo, y corregir nuestra prueba. Podemos tomar la entrada y decir, oh, no debería tener un valor de cero.

Y luego continuaríamos y haríamos clic en esto. También podemos echar un vistazo a las solicitudes de red, ¿verdad? Esto es, de nuevo, la misma prueba de Cypress. El problema habitual con estas llamadas API es que son asíncronas, ¿verdad? Realmente no esperamos la respuesta. No nos impiden hacer cosas en la página. Así que tal vez hicimos clic demasiado pronto. Eso es exactamente lo que pasó en esta prueba.

Entonces, lo que Cypress hace con estas solicitudes XHR es que tomará una instantánea en el momento de la solicitud y tomará una instantánea en el momento de la respuesta. Así que aquí estamos acercándonos al endpoint de comprobación de disponibilidad. Así que hay un endpoint que comprueba si las zapatillas están disponibles. Y luego, en algún momento, hacemos clic en el botón. Ahora, en la instantánea de la respuesta, puedes ver que vemos el mensaje de fallo al añadir el producto al carrito. Y esto demuestra que hicimos clic en el botón Añadir al Carrito antes de que llegara la respuesta del endpoint de comprobación de disponibilidad. Y esta, de nuevo, es información de la máquina del tiempo, de la línea de tiempo, que podemos usar para hacer nuestra prueba más estable. Por ejemplo, en Cypress, podemos usar intercept para capturar una cierta llamada API, y luego esperar a que nos dé la respuesta, y sólo entonces pasar a la siguiente prueba.

Aquí hay otra cosa. Aquí está Playwright. Este es un visor de trazas que nos proporciona observabilidad de acciones. No estoy seguro de cuánto puedes ver eso, pero estoy señalando esta parte inferior aquí. Esta es toda la información, todos los registros, de lo que sucede cuando intentas hacer clic en algo. Así que puedes ver que estamos comprobando si el elemento en el que estamos intentando hacer clic está disponible, no está deshabilitado, no está cubierto por nada más, etc. Y porque nuestra prueba está fallando en la comprobación de visibilidad, ¿verdad? Queremos ver aparecer un mensaje y no está allí. Podríamos estar intentando mirar atrás y tratar de mirar los comandos que estaban antes, para que podamos descartar que hay un problema con el evento de clic o algo así. Y, de nuevo, esto nos ayuda a reducir los problemas, y podemos ver qué está pasando con nuestra prueba. Podemos ver qué está mal. Otro ejemplo, tenemos las salidas de la consola. En este caso, la inestabilidad en las pruebas puede estar señalando un problema real, y eso es importante. Y el problema real puede ser intermitente, pero si tenemos los registros de nuestra aplicación, los registros de la consola, esto puede ayudarnos mucho. Otro ejemplo en la Máquina del Tiempo de Playwright es la definición de la prueba. Nos ayuda específicamente si tenemos, si estamos lidiando con escenarios más complejos. Y sí, así que tenemos todas estas opciones, lo que me lleva a reiterar un punto que hice antes.

Las máquinas del tiempo son geniales. Muy bien. Pero hay un problema en el que he estado pensando mucho, especialmente en relación con la inestabilidad en las pruebas en las máquinas del tiempo. Recientemente hice la siguiente pregunta a las personas en LinkedIn. Si tu aplicación y servidor fueran completamente libres de inestabilidad, ¿qué crees que sucedería? ¿Qué pasaría con tus pruebas? ¿Serían menos inestables, tan inestables como antes, más inestables, o algo más? La gran mayoría dijo que sus pruebas se volverían menos inestables. Y quizás nadie lo ha expresado mejor que Corey House aquí. Agregar pruebas automatizadas a una aplicación inestable conduce a pruebas inestables. Y estoy totalmente de acuerdo. Así que hablamos mucho sobre la inestabilidad en las pruebas. Hablamos a menudo sobre la inestabilidad en la aplicación. Y necesitamos hablar de ello.

Así que volvamos a la solución de antes, donde interceptaría la llamada a la API. Algo no me cuadra con esta prueba. Nuestros usuarios no esperan a los puntos finales de la API. Y pueden encontrarse fácilmente con el mismo problema que nuestras pruebas, porque pueden tener una red más lenta, o pueden tener una CPU más lenta, o lo que sea. Lo cual no es bueno.

Entonces, de todas las formas en que podemos aprender del pasado, siempre podemos encontrar algún problema. Podríamos no tener suficiente información, no somos capaces de replicar, la depuración es difícil y frustrante, y también con las máquinas del tiempo, estamos ignorando la aplicación. Entonces, ¿cuál es la solución? Bueno, creo que podría tener una. Y quiero mostrártela.

Así que hace tres meses, me uní a una empresa llamada Replay.io. Quizás hayas oído hablar de ellos. Y creo que resuelve estos problemas. Y podrías decir que estoy sesgado. Lo sé, porque trabajo para Replay. Pero me convertí en fan antes de unirme a la empresa. Así que creo... Bueno, tú serás el juez de eso. Muy bien.

Así que déjame explicarte cómo funciona. El principio es bastante simple. Hemos construido un depurador de viaje en el tiempo. Y la idea es que creas una grabación de tu aplicación. Y luego abres esa grabación en las herramientas de desarrollo. Y puedes crear una grabación de muchas maneras. Puedes hacerlo manualmente. Así que tenemos nuestro navegador que puedes abrir, pulsar el botón de grabación, y luego empezar a interactuar con tu aplicación. Tenemos una CLI que abrirá el navegador por ti. Así que puedes, de nuevo, crear esa grabación manualmente. Y cerrar el navegador. Y tienes una grabación disponible para ti.

O, dado que es un navegador, en realidad puedes usarlo con Cypress. Y el npx-cypress-run-browser-replay-chromium sería cómo lo ejecutarías. Y luego npx-playwright-test. Esta sería la configuración para Replay Chromium. Por cierto, todo esto está en nuestros documentos. Así que puedes consultarlos. También soportamos WebDriver, IOPuppeteer, o incluso Selenium. Entonces, sí.

Esa es la parte de grabación, ¿verdad? Entonces, ¿qué hacemos con la grabación? En realidad, permíteme mostrarte la parte de depuración de la experiencia. Voy a cerrar mi presentación. Cambio a la duplicación de la pantalla. Y esperamos poder continuar. Muy bien. Esto parece estar funcionando. Muy bien. Así que aquí tengo una grabación de la misma aplicación que te he estado mostrando. Tenemos esta tienda de e-commerce. Y aquí abajo tenemos una línea de tiempo. Y puedo reproducir esto como un video. Déjame reproducir eso desde el principio. ¿Verdad? Así que abres la aplicación y puedes verme iterando en el contador, pulsando uno, dos, tres, etc. Ahí es donde termina la grabación. En el lado izquierdo aquí, ves que tenemos este evento de clic. Así que no es solo un video. En realidad es una grabación de la interacción. Ahora lo que podemos hacer aquí es hacer clic en este botón azul aquí. Podemos saltar al código que me cambiará a este panel de DevTools. Y podemos ver el código que se ha ejecutado cuando hicimos clic en ese botón más aquí en la aplicación. Ahora esta es una herramienta colaborativa. Así que si no estás en el lado de la automation de pruebas, tal vez eres un ingeniero de QA en una sesión exploratoria y quieres pasar eso al desarrollador para que se ocupe de eso, puedes simplemente seguir adelante y agregar un comentario.

Como esta no es una imagen correcta o hola o lo que sea. De esta manera, no pueden decirte que no pueden reproducirlo. Porque tienes esa grabación, tienes la prueba y realmente tienes el código aquí dentro.

Entonces, lo que eso significa es que si miras aquí, el salto al código me ha llevado al componente que realmente se activó cuando estaba haciendo clic en ese botón más. Ahora aquí a la izquierda, hay esta columna, y este número 10 que ves aquí en realidad me está diciendo cuántas veces se golpeó esta línea de código. Así que eso ya es información útil. Funciona como la cobertura de código, donde puedes ver qué líneas de código fueron golpeadas y cuáles no.

Y lo que puedes hacer es hacer clic en este símbolo más, y en la consola ahora puedes ver todas las instancias donde se llamó a esa línea de código. Así que está este control de texto por defecto y el número de línea nueve. Pero lo que puedo hacer para obtener algo de información es imprimir alguna variable. Por ejemplo, esta cantidad aquí. Y ahora puedo ver la variable de cantidad que se ha pasado a esta función setQuantity, y puedo ver cómo ha cambiado con el tiempo. Y puedo retroceder o avanzar.

Ahora hay algunas personas que están usando el depurador. Bueno, puedes usar el depurador aquí, no solo las declaraciones de impresión. Así que añadí un punto de interrupción haciendo clic en este número nueve, y ahora puedo retroceder y debug esto, ¿verdad? Así que vamos a la línea de tiempo. Vamos a ver este panel de Scopes aquí. Espera, en realidad, vamos a saltar al punto de interrupción. Tenemos la cantidad dos, así que podemos avanzar, o podemos retroceder. Espera, déjame esperar a que esto se cargue. Ahora tenemos la cantidad tres. Sigamos hacia atrás hasta la cantidad dos. Así que si has usado puntos de interrupción y depurador, podrías haber hecho clic accidentalmente una vez más de lo necesario. Supongo que todos han sentido eso. Así que si tienes esa grabación y estás depurando la grabación, puedes moverte hacia atrás y hacia adelante.

Ahora, normalmente cuando haces debug, la forma en que lo haces es que modificas tu código. Añades un registro de consola en algún lugar o añades esa declaración de depurador en tu código, y luego lo ejecutas y tratas de replicarlo y esperas que puedas llegar a ese problema. Y necesitas hacer eso varias veces. Con Replay, si tienes esa grabación, en realidad puedes grabar, capturar el error una vez, y luego añadir esas declaraciones de impresión y lo que sea, en cualquier momento que necesites. Además, si quieres compartir eso, puedes hacer clic en el botón de compartir y enviarlo a quien necesite arreglar eso.

Muy bien. Hay una cosa más que quiero mostrarles. Mencioné que la grabación, la haces con nuestro navegador replay. Y puedes conectar el navegador a tu suite de pruebas. Así que si estás utilizando Playwright o Cypress, puedes simplemente crear tus grabaciones automáticamente.

Pasemos ahora a esta grabación que he hecho con la prueba de Cypress. Ahora en esta, lo que hice es que ejecuté mi prueba y falló la primera vez, luego falló la segunda vez, y finalmente pasó. Así que ahora puedo comparar mi prueba fallida y mi prueba aprobada. Si voy a la prueba fallida y miro este clic, de nuevo tengo esta función de salto al código así que puedo ver en qué estaba haciendo clic mi prueba de Cypress y qué parte del código fue ejecutada mientras Cypress lo hacía. Y puedes ver aquí que ha llamado a esta función añadir al carrito, que llama a la API de añadir al carrito. Y en el cuerpo, estamos enviando la cantidad que está aquí. Ahora la cantidad es un estado que es cero por defecto. Y el estado se muta aquí en el set quantity. Lo estamos estableciendo después de obtener la respuesta del check availability. Así que si añadimos un par de declaraciones de impresión aquí, déjame, en realidad me estoy quedando sin tiempo así que necesito hacerlo rápido. Estableceré sent to server de esta manera. Podemos ver lo que se ha enviado al servidor, ¿verdad? Hemos estado enviando el número cero. Si imprimo estos data, QTI e imprimo availability, puedo ver lo que ha venido del servidor, ¿verdad? Y esta es una línea de tiempo así que en realidad puedo ver en qué orden se hizo esto. Así que estamos enviando el número cero y no estoy seguro de por qué esto no se está cargando pero al menos puedes ver que estamos en vivo. Si echamos un vistazo a toda la prueba, puedo ver la diferencia entre la instancia aprobada y la instancia fallida, que ahora se está cargando. Así que aquí tenemos el intento fallido, el intento fallido y luego finalmente tenemos el intento aprobado donde finalmente estamos enviando la información, ordenando un sneaker y no cero sneakers. El tiempo me está parpadeando así que necesito terminar esta charla. Básicamente mi punto aquí es que algo está sucediendo en el código. Tenemos algunas operaciones asíncronas que no están jugando bien con nuestra prueba. Si deshabilitáramos este botón de añadir al carrito mientras tenemos la cantidad establecida en cero, nosotros en realidad solucionaríamos todos los problemas con nuestras pruebas porque Cypress y Playwright, ellos verifican si el botón en el que queremos hacer clic es realmente accionable. Así que no tenemos que esperar el intercept. No tenemos que afirmar que el número no es cero. La prueba pasaría mágicamente sin ninguna modificación.

Sí, volviendo a mi presentación, tengo dos diapositivas finales donde quiero demostrar que básicamente replay resuelve el problema de la falta de información. Si puedes replicarlo una vez tienes suficiente información.

Además, la depuración, si simplemente grabas lo que sucedió, puedes agregar una declaración de impresión, depurador. Tenemos Redux, React DevTools, Estado de Redux, etc. Y lo más importante, no estamos ignorando la aplicación que estamos testing, lo cual creo que es un gran error que se comete cuando hacemos las pruebas de extremo a extremo y cuando estamos lidiando con la fluidez de las pruebas.

Muy bien, esa es mi charla. Muchas gracias. Ven a hablar con nosotros. Tenemos un stand. Y gracias. Sé que hubo muchas preguntas. Definitivamente no podremos responder a todas ellas. Pero lo que haremos es que después la gente puede encontrarte en el stand de replay. Sí, definitivamente ve a echarle un vistazo. Voy a ir a la pregunta más votada. Haremos esa y luego lo dejaremos.

¿Es más lento ejecutar pruebas en el navegador de replay que en los navegadores reales? Y si es así, ¿cuánto? No lo sé. No lo he medido. No creo que si hay una diferencia sea muy significativa. Esencialmente lo que tenemos es una bifurcación de Chromium. Así que no creo que la diferencia sea tan grande. Pero no podría decirte cuán grande es la diferencia. Y eso también tiene sentido, porque una pregunta que me ha intrigado mucho es específicamente con las pruebas inestables, primero tienes que encontrar una prueba inestable. El hecho de que sean difíciles de encontrar es interesante. ¿Y cuánto tiempo ha ahorrado tal vez? ¿Has visto en la vida real que ahorra mucho tiempo tal vez en un proyecto donde replay ayudó a encontrar esa prueba inestable? Una cosa que he dejado fuera de mi presentación fue otra encuesta que hice en LinkedIn donde preguntaría como, ¿pasas más tiempo depurando o escribiendo tus pruebas? Y la depuración de pruebas fue la mayoría abrumadora. Recientemente hemos estado mirando los fallos de un cliente nuestro y trataríamos de encontrar las razones de esos fallos. Ahora ocurrió algo muy gracioso. Hemos encontrado una prueba inestable que en realidad debería estar fallando porque estaba dando un falso positivo. Debería estar fallando todo el tiempo, pero estaba fallando intermitentemente. Y el problema era que había esta comprobación de accessibility que estaba revisando el sitio. Pero luego el equipo de marketing entró y añadió como un modelo, Hey, ¿quieres una nueva experiencia o lo que sea? Eso no era accesible.

Así que la comprobación de accessibility fallaría dependiendo de si capturó la ventana del modelo o no. Y probablemente debería fallar todo el tiempo si quieres ser conforme a accessibility. Eso también es una locura porque probablemente sean diferencias de milisegundos las que determinarían si la prueba ha pasado o ha fallado, lo cual es una locura. Quiero decir, todas las pruebas inestables lo son. Ese es el problema porque estamos ejecutando nuestras pruebas super rápido, lo que podría parecer que es poco realista. Pero si ralentizas todo, si ralentizas la red o el procesador, creo que lo que sucede en CI simplemente está sucediendo más rápido a lo mismo que está sucediendo más rápido que puede estar sucediendo a algún usuario con una red muy lenta y una CPU muy lenta. Eso tiene sentido.

Voy a volver a las preguntas del público. Esto tiene sentido, especialmente cuando hablamos de velocidad, porque la persona preguntó como, ¿recomendarías testing toda su suite en el navegador replay en cada ejecución de CI? Supongo que eso podría llevar tiempo, pero tengo curiosidad por saber si lo tendrías en ejecución. Creo que tendría sentido, especialmente al principio cuando estás implementando y quieres deshacerte de los fallos. Entonces, si tu tasa de inestabilidad es realmente alta, entonces puedes hacer eso. Pero hay otra forma de cómo puedes abordarlo. Tal vez puedes ejecutar todas tus pruebas. Y si alguna de ellas fue inestable o falló, puedes volver a ejecutar con solo ese subconjunto. Así puedes atrapar solo las problemáticas y luego debug con DevTools. Así que creo que ese también podría ser un buen enfoque. Entonces, por lo que estoy escuchando, y creo que, de nuevo, los replays son herramientas y las herramientas tienen diferentes usos, ¿dirías que los replays son más para profundizar en un problema específico en contraposición a una red amplia para atrapar muchos problemas? ¿Quizás ambos? Creo que puede ser ambos porque si tienes una suite de pruebas y tal vez como el 20% de tus pruebas son inestables, tal vez las vuelvas a intentar y todas están bien, pero eso no es algo que quieras tener a largo plazo. Quieres reducir eso. Y para eso, necesitas sumergirte y mirar los detalles. Y creo que tener no solo el código de prueba, sino también el código de la aplicación disponible. Creo que eso es un cambio de juego. Ahí es donde realmente puedes solucionar el problema. Y no solo en el lado de la prueba agregando un peso o interceptando o lo que sea, sino realmente arreglar el código, ¿verdad? Porque eso es lo que está causando la inestabilidad. No, totalmente. Muy bien. Esta última pregunta, vamos a tener que pasarla rápidamente. Pero tienes una tienda web, ¿verdad? La experiencia del cliente es un error, los desarrolladores intentan replicar ese error ellos mismos. ¿Cómo pueden obtener ese error del sitio web que experimentó el cliente a su depurador de replay? Esa es una buena pregunta. Como, desafortunadamente, no creo que haya una forma de cómo podemos decirles a nuestros clientes que navegador replay. No estoy seguro de si eso sería útil. Tal vez habría un escenario. No lo sé. Pero lo bueno es que si atrapas el error, solo necesitas atraparlo una vez. Sin el navegador replay, creo que podrías, si realmente quieres solucionar el problema, podrías necesitar replicar ese problema varias veces y necesitarás reducir y encontrar esos pasos para replicar, lo cual es mucho, mucho más difícil que simplemente atraparlo una vez. Así que creo que ahí es donde brilla el replay. Me encanta. Incluso si el error ocurre una vez, puedes repasarlo varias veces. Muchas gracias. ¡Aplaudamos a Filip! Gracias. Gracias. Gracias. Gracias. Gracias.