1. Introducción al Triaje de Suite de Pruebas
Al final de esta charla, todos ustedes también pueden convertirse en Tribus de Tiempo JS. Esta charla se llama deja de hacer triaje a tu suite de pruebas. Si tienes código, va a haber errores. Y si tienes errores, vas a tener pruebas inestables. Vengo de replay.io. Estamos construyendo las primeras herramientas de desarrollo de navegador con capacidad de viaje en el tiempo.
Al final de esta charla, todos ustedes también pueden convertirse en Tribus de Tiempo JS. Así que antes de comenzar, levanta la mano si tienes una suite de pruebas de navegador. Bien. Vale. Levanta la mano si tienes más de 10 pruebas. Mantenlas arriba si tienes 20. Muy bien. ¿50? ¿Tenemos 50? Vale. ¿Oigo 100? Correcto, correcto, correcto. ¿Algunos miles? Ah, vergüenza para todos ustedes.
¿Qué tal Selenium? ¿Quién usa Selenium? ¿Playwright? ¡Demonios! ¿Puppeteer? Vale, vale. ¿Cypress? Genial. ¿Quién tiene pruebas inestables? Pensé que eso podría pasar. ¿Quién ha arreglado su prueba inestable este año? ¿En los últimos seis meses? ¡Yay! ¿Tres meses? ¿Quién ha arreglado su prueba inestable en la última semana? ¡Sí! ¡Sí! Así que esta charla se llama deja de hacer triaje a tu suite de pruebas. Para mí, hacer triaje es cuando estableces reglas como ah, si es inestable más de esta cantidad, es decir, falla durante más de este tiempo, vamos a tener que empezar a saltárnoslas. Tenemos que conseguir que alguien en algún lugar lo arregle. Y eso me duele. Todo el mundo a gran escala ha establecido algún tipo de política sobre sus pruebas inestables. Y han desactivado algunas de nuestras pruebas inestables. Y eso me duele. Pero la realidad es que si tienes código, va a haber errores. Incluso esta diapositiva tiene un error. ¿Quién ve el error? ¿Cuál es el error? Sí, hay una segunda I. Tres I's. No debería haber una segunda I. Pero hay errores en todas partes. Y si tienes errores, vas a tener pruebas inestables. Entonces, vengo de replay.io. Un grupo de nosotros de Mozilla comenzó replay hace tres años.
2. Observaciones sobre las Suites de Pruebas
Hemos estado hablando con cientos de equipos sobre sus pruebas de navegador. Las pruebas son más difíciles a gran escala. Todo el mundo culpa a sus pruebas. La inestabilidad proviene de la aplicación. Los pequeños equipos de QA luchan por mantener la suite de pruebas. Se necesita todo un equipo para comprarlas y mejorarlas de manera confiable.
Y estamos construyendo las primeras herramientas de desarrollo de navegador con capacidad de viaje en el tiempo. También somos los del sombrero de cubo. Si quieres un sombrero de cubo de pato genial, ven más tarde. Los tenemos. Nos encantaría dar te los. Y durante los últimos años, hemos estado hablando con cientos de equipos sobre sus pruebas de navegador. Así que, pensé en compartir un par de observaciones antes de saltar a algunas demostraciones. Charla realmente, realmente simple. Quiero hacer tres demostraciones. Entonces, primera observación. Las pruebas son más difíciles a gran escala. Pensarías que sería más fácil a gran esccala, pero hemos hablado con las empresas más grandes del mundo, y, sí, Facebook y Apple y Google están luchando, y tienen todas las pruebas. Entonces, a medida que se hace más grande, se hace más difícil. Eso es triste. En segundo lugar, todo el mundo culpa a sus pruebas. Son como, ugh, no puedo escribir pruebas estables en
Cypress. Voy a cambiar a Playwright. También va a ser inestable allí, porque la inestabilidad proviene de la aplicación. Sí, seguro, hay algunas pruebas malas debido al código, también. Pero hay mucho más código de aplicación y código de
backend que está causando inestabilidad. Tenemos que entender eso.
Esto me toca personalmente. Veo a estos pequeños equipos de QA tratando de mantener la suite de pruebas, y no pueden. Y luego veo a estos otros equipos, a veces en empresas realmente grandes, donde un desarrollador dice, tenemos que tener una suite de pruebas. Bueno, seguro. La traen, escriben muchas pruebas. Los desarrolladores miran la prueba, y son como, está fallando un poco. No quieren tocarlo. Entonces, es como, soy esa única persona que intenta mantener esto vivo, y están aguantando y apostaron su carrera en, como, hey, creo que deberíamos tener pruebas. Pero la gente empieza a volverse contra las pruebas y a culpar a las pruebas. Se necesita todo un equipo para comprarlas,
3. Entendiendo la Salud de la Suite de Pruebas y Demostraciones
El producto y el equipo de QA deben trabajar juntos para entender tanto las suites de pruebas como la aplicación. La salud de una suite de pruebas se puede medir por el número de pruebas y contribuyentes. Las pruebas de extremo a extremo pueden mantenerse fácilmente y tener un ROI positivo. Las mejores suites de pruebas contribuyen a entregar valor y cambiar con confianza. Ahora, pasemos a las demostraciones.
pero para comprar, tienes que tener una forma de mejorarlas de manera confiable. De lo contrario, la inestabilidad es dura. El producto y el equipo de
QA deben estar involucrados. Veo todos estos equipos donde es como el equipo de
QA o el equipo de producto. Nunca es como, hey, ¿podemos trabajar en esta suite de pruebas juntos? Porque el equipo de
QA entiende las suites de pruebas, y el equipo de producto entiende la aplicación. Tienes que entender ambos para tener una gran suite de pruebas.
Creo que puedes medir la salud de la suite de pruebas con dos gráficos que nadie mira. El primero es cuántas pruebas tienes, ¿y eso está subiendo? ¿O eso, como, se ha estancado? O, muchas veces, bajando porque añadiste las pruebas? Y están siendo lentamente omitidas, desactivadas, eliminadas, etc. Y el otro gráfico es cuántas personas están contribuyendo a la suite de pruebas. Sí, tenías a todos estos desarrolladores emocionados por la suite de pruebas, pero ahora es un poco doloroso, y está bajando lentamente. Está en esa única persona, como, mantenerla viva. Si puedes conseguir una suite de pruebas que está creciendo a medida que tu aplicación crece, y está obteniendo más y más contribuyentes, porque más personas se preocupan por la prueba y ven el ROI, eres saludable.
El estado de las pruebas de extremo a extremo no me parece saludable. Sí, es posible. Hemos estado ayudando a los equipos a mejorar su suite de pruebas y, como resultado, han estado contentos con su prueba, añadiendo más pruebas. Es posible hacerlo. Siento que tengo que poner eso a veces, porque hay tanta ansiedad alrededor de la suite de pruebas de extremo a extremo. Oh, tenemos que salir de las pruebas de extremo a extremo y usar pruebas unitarias, porque esas son más mantenibles. Si puedes crear una gran suite de pruebas de extremo a extremo, puedes mantenerla incluso más fácil que una prueba unitaria, porque son simples y deberían ser simples, clic, tecleo, etc. Y luego, por último, para todos los VPs de ingeniería por ahí, de los cientos de equipos con los que he hablado, los equipos que están entregando más valor a sus usuarios también tienen la mejor suite de pruebas. La suite de pruebas es lo que les ayuda a cambiar con confianza. Así que realmente hay un ROI en el otro lado. Muy bien. Pasemos a las demostraciones. Así que tengo tres demostraciones hoy. La primera es nuestra pequeña aplicación de comercio electrónico Hello World. Es un pequeño hoverboard. Y vas a comprar algo, y no puedes comprar el hoverboard. Esa es toda la aplicación. Así que esta prueba se ejecutó, veamos, se ejecutó hace dos días. Pero con Replay, cuando estamos en Replay DevTools, dice si la aplicación está funcionando localmente en tu ordenador en este momento, y tienes el
4. Depuración con Replay DevTools
Puedes ver los elementos que fueron seleccionados. Cuando hago clic en el botón especial 'saltar al código', me lleva a Replay DevTools, donde puedo depurar la aplicación como si estuviera funcionando en vivo. Entender el problema y solucionarlo es fácil una vez que descubres qué salió mal. Eso es Replay en esencia.
Con la aplicación
Cypress abierta, el panel aquí te permite ver cómo se ven las pruebas en cualquier punto. Puedes ver los elementos que fueron seleccionados. Todo debería funcionar, pero hay este botón especial aquí, saltar al código. Y cuando hago clic en él, me lleva a Replay
DevTools, y estoy pausado en el componente que está manejando ese clic. Y ahora que estoy pausado aquí, puedo ver que el clic inició una búsqueda. Así que puedo saltar hacia adelante y puedo pasar el ratón por, digamos, los datos del formulario
data y ver el valor. Puedo ver qué era form.action, que es donde se inició la API. Puedo saltar hacia adelante en el tiempo. Y cuando salto hacia adelante en el tiempo, puedo pasar el ratón por la respuesta y esto no estaba bien. Salto un poco más adelante, paso el ratón por el mensaje de error, veo eso también. Puedo depurar la aplicación como si estuviera funcionando en vivo y acaba de fallar por primera vez. Por supuesto, tienes
React DevTools, puedes especificar componentes, y en este caso, también puedes encontrar una búsqueda y ver la búsqueda original que se inició, la solicitud, y el cuerpo de la respuesta. Y una vez que entiendes el problema, en realidad solucionarlo es bastante fácil,
5. Analizando el Comportamiento del Desplegable
Esta aplicación es Metabase, que ofrece una herramienta para consultar bases de datos y escribir consultas SQL. El desplegable en la prueba muestra diferentes opciones dependiendo de si pasa o falla. Al inspeccionar el componente y el código fuente, podemos identificar la función responsable de determinar los elementos del desplegable. Agregar un registro de consola ayuda a depurar el problema, revelando que la prueba falló y solo se muestra un elemento.
pero la clave es poder averiguar qué salió mal. Así que eso es Replay en esencia. Esta es nuestra aplicación Hello World. Pasemos a las más interesantes. Así que esta aplicación es Metabase. Y Metabase ofrece una herramienta que básicamente te permite consultar tu
database. Así que es bueno para escribir consultas SQL. Y cuando la prueba falla, este desplegable aquí muestra un elemento. Pero cuando la prueba pasa, el desplegable, oh, es tan rápido, los testers son tan rápidos estos días. El desplegable tiene dos. ¿Ves cómo dice como usar valor original y personalizado? Eso es lo que está bien. Pero en el caso de fallo, solo dice usar original. Así que averigüemos por qué. Voy a saltar a esta prueba. Y si quiero encontrar el componente del que estamos hablando, podría saltar en este clic, que me llevará al desplegable, que estamos abriendo. Incluso puedes ver que hay un interruptor aquí y todo. Pero una cosa mejor que hacer sería usar las herramientas de desarrollo de
React, encontrar el componente aquí mismo, desplazarse hacia arriba porque Metabase es masivo. Así que todos estos componentes están envolviendo la cosa que es este componente de configuración de mapa de campo. Puedes ver que hay un campo aquí, una tabla, todas esas cosas buenas. Voy a saltar al código fuente. Puedes ver que las tres opciones para el desplegable son original, extranjero y personalizado. No nos importa el extranjero, pero voy a tomar esta variable y buscar en el código. Así que lo primero aquí es un poco aleatorio, así que voy a saltar más allá de eso. Y ahora tenemos esta función llamada get available mapping types. Y esta es la función que el componente utiliza para averiguar qué elementos del desplegable incluir en el componente. Y lo que voy a hacer es simplemente añadir un registro de consola porque el registro de consola es la mejor depuración. Añade el registro de consola, vuelve a ejecutar. En nuestro caso, puedes añadir un registro de consola haciendo clic en este botón de más y ya está. Así que lo hago clic y ahí están los registros de consola. Pero voy a cambiarlo para registrar la única variable que realmente importa, los tipos de mapeo. Y esta cosa es la lista que aparece en el desplegable. Así que aquí podemos ver que es solo un elemento porque la prueba
6. Analizando el Fallo de la Prueba
Si es una cosa numérica mapeable, inclúyela; de lo contrario, no. La variable de remapeo está vacía, por lo que no tenemos lo que necesitamos. El campo no tiene valores en remapeo. Los datos estaban vacíos y la solicitud de red no tuvo respuesta.
falló y solo muestra un elemento. Pero si salto a esta otra prueba donde pasó y encuentro el mismo archivo y encuentro esa misma función obtener tipos de mapeo disponibles. Ahí estás. Y agrego el mismo registro de consola. Hay dos. Y son original y personalizado. Entonces la pregunta es, como, OK, genial. Solo está haciendo una cosa. ¿Por qué solo está haciendo una cosa? Bueno, hay esta función aquí donde dice, como, si es una cosa numérica mapeable, genial, inclúyela, de lo contrario no. Así que vamos a encontrar donde se define esta cosa mapeable. OK. Está justo arriba. Y esta cosa está mirando la variable de remapeo y diciendo, oye, ¿tiene alguna clave que haga estas cosas? Yada, yada, yada. Todo lo que realmente me importa es remapeo. Y puedo ver que la respuesta no es realmente. El mapa está vacío. Y porque el mapa está vacío, no tenemos lo que necesitamos. Y podemos ver rápidamente que el campo es este campo y no tiene nada en remapeo. Y si queremos ver de dónde el campo está obteniendo sus valores, bueno, ellos usan
redux. Así que vamos a comprobar aquí. Seguro. Y aquí, y aquí, tenemos un campo. Tenemos una búsqueda. Creo que debería haber valores de campo aquí también, esto es algo aleatorio para mí. Valores de campo. Y lo siento, los
data estaban vacíos. Sin valores. Y luego el monitor de red mostrará lo mismo. Así que podemos pasar de, como, oye, el componente
React hizo esto por esta razón a
redux, obtuvo estos
data, pero estaba
7. Analizando el Tablero de la Suite de Pruebas
Este es un ejemplo de una prueba en el tablero de la suite de pruebas de Replay que estaba fallando pero se mostraba como aprobada. La prueba afirma que hay cinco pruebas inestables, pero todas aparecen como aprobadas. Al usar las DevTools de React, podemos investigar la prueba y encontrar el problema. Agregar una condición al camino de test.source ayuda a identificar el problema.
incompleto para la solicitud de red, y la respuesta no tenía nada. Trabajando hacia atrás. Todo bien. Ejemplo 3. Así que esto va a parecer realmente meta. Porque lo que estamos viendo aquí es el tablero de la suite de pruebas de Replay. Y esta es una prueba que nosotros mismos escribimos que estaba fallando toda la semana pasada, que creo que arreglamos ayer. Pero estoy aquí, no allí. Así que no estoy 100% seguro. Solo creo que ese es el caso. Y lo otro que es meta sobre esta prueba es que la prueba está afirmando que hay cinco pruebas inestables. Y dice que hay cinco pruebas inestables aquí, y dice que hay cinco pruebas inestables allí en la insignia amarilla. Pero todos estos resultados aparecen como aprobados. Así que lo que estamos diciendo aquí es que la prueba para mostrar resultados fallidos está fallando porque cree que la prueba pasó, pero realmente falló. Lo siento. Hay, como, muchos niveles de inception pasando aquí. Pero podemos hacer lo mismo. Nosotros usamos
React DevTools. Encontramos el elemento de la lista de resultados de la prueba aquí. Miramos la prueba en cuestión. La prueba tuvo un resultado de inestable, por lo que cree que fue inestable, pero aún así la mostramos como aprobada. Podemos saltar a la prueba aquí. Esta parte es un poco extraña, así que ten paciencia conmigo. Si agrego un const log, y registro el paso de test.source, vas a ver muchas de estas cosas, como 180 de ellas. Demasiadas renderizaciones. Pero quiero encontrar la correcta, así que voy a ir a
react, y simplemente voy a agarrar esta, los comentarios autenticados02. Simplemente no quiero escribir, así que ten paciencia conmigo. Comentarios01. Genial. De acuerdo. Y ahora voy a añadir una condición. Test.source path igual a esta cosa.
8. Reproducibilidad y Depuración Colaborativa
Y ahora solo vamos a ver los que nos interesan. La prueba fue inestable, pero esta etiqueta que se está pasando dice que pasó. Con las herramientas de desarrollo de Replay, conseguimos resolver el problema de la reproducibilidad. Las pruebas que fallan el uno por ciento de las veces son difíciles de depurar porque fallan el uno por ciento de las veces, y a menudo no en tu ordenador, solo en CI. Si puedes obtener una grabación, puedes depurarla como si se reprodujera cada vez. Y con Replay, porque es una máquina del tiempo, puedes trabajar hacia atrás. Las pruebas inestables son difíciles porque los problemas de tiempo son realmente difíciles de entender. Pero cuando tienes una máquina del tiempo y puedes trabajar hacia adelante y hacia atrás y acotar el problema, algunos de los errores más difíciles se vuelven fáciles.
Y ahora solo vamos a ver los que nos interesan. Genial. Y puedo pausar aquí, y veré que la prueba, de hecho, pasó. Debería haber fallado. Gracias. Errores por todas partes. Mucho mejor. Vale. Y la prueba fue inestable, pero esta etiqueta que se está pasando dice que pasó. Está mintiendo. ¿Por qué está mintiendo? Bueno, me estoy quedando sin tiempo, así que si quieres saber por qué está mintiendo, puedo compartir el replay contigo más tarde. O es de código abierto, así que puedes comprobarlo tú mismo. Volviendo a la charla. Por cierto, esta charla, que puedo compartir, tiene un enlace justo allí.
Entonces, ¿de qué hablamos? Con las herramientas de desarrollo de Replay, conseguimos resolver el problema de la reproducibilidad. Las pruebas que fallan el uno por ciento de las veces son difíciles de debug porque fallan el uno por ciento de las veces, y a menudo no en tu ordenador, solo en CI. Si puedes obtener una grabación, puedes debug como si se reprodujera cada vez porque la tienes justo allí. Y con Replay, porque es una máquina del tiempo, puedes trabajar hacia atrás. El coche ha chocado contra el árbol. Puedes rebobinar el reloj hasta cuando el coche estaba zigzagueando y desviándose antes de chocar contra el árbol. Podemos empezar con el componente de React que tiene un desplegable que parece mal y trabajar hacia atrás hasta el estado que causó que el componente se renderizara de la forma en que lo hizo y luego de dónde vino el estado. Podemos colaborar. Podemos trabajar en equipo. Puedes empezar a depurar una prueba inestable y decir hasta aquí he llegado. Voy a dejar algunos comentarios y mencionar a otras personas del equipo que pueden echarle un vistazo. QA puede avisarte. Puedes colaborar. Y no puedo enfatizar esto lo suficiente. Las pruebas inestables son difíciles porque los problemas de tiempo son realmente difíciles de entender. Pero cuando tienes una máquina del tiempo y puedes trabajar hacia adelante y hacia atrás y acotar el problema, algunos de los errores más difíciles se vuelven fáciles.
9. Entendiendo Replay y Time Machine Replay
Y eso es Replay. ¿Es Replay un marco de pruebas individual o siempre depende de algo como Play Right y demás? Replay es un navegador. Lo hemos enseñado a Chrome cómo grabar y reproducir de manera determinista más tarde. Una recomendación práctica para mejorar las suites de pruebas de extremo a extremo es agregar Replay. Internamente, la reproducción de la máquina del tiempo funciona capturando toda la comunicación con el sistema operativo y dándole el valor de antes.
Y eso es Replay. Y espero que todos puedan dejar de clasificar sus pruebas y tener buenas pruebas.
Una pregunta es simplemente tratar de entender el encuadre de lo que es Replay y cómo hablamos sobre ello. ¿Es Replay un marco de testing individual o siempre depende de algo como Play Right y demás? Oh, vaya. Replay es un navegador. Ahí vamos. Lo hemos enseñado a Chrome cómo grabar y reproducir de manera determinista más tarde. Genial. Gracias. Eso ayuda. Me alegro de que hayamos aclarado eso. Está todo bien. Bueno. ¿Cuál es una recomendación práctica que los equipos pueden adoptar ahora mismo para mejorar sus suites de pruebas de extremo a extremo? Añadir Replay. Vaya. Bueno, estamos respondiendo rápidamente a estas, ¿no? Esta es realmente una pregunta muy interesante si puedes hablar un poco sobre ella. Internamente, ¿cómo funciona la reproducción de la máquina del tiempo? La clave es poder reproducir. Entonces, si te di una función, Fibonacci, tienes la función. Tienes la entrada. No necesitas grabar nada. Simplemente lo ejecutas de nuevo. Si cambias Fibonacci para que en lugar de tomar la entrada, lea la entrada de un archivo, eso es lo que necesitas grabar. La próxima vez que lo ejecutes, piensa que está leyendo del archivo, pero solo has capturado esa una pieza. Es como MSW, pero para software. Lo que hemos hecho con Chrome es que le hemos enseñado a capturar toda la comunicación con el sistema operativo para que más tarde piense que está funcionando en tu ordenador. Piensa que es ayer. Piensa que está haciendo todas esas llamadas a la API. Cada vez que hace una llamada al sistema del sistema operativo, la capturamos
Uso de Replay para la depuración de pruebas
Siempre puedes hacer preguntas de seguimiento a través de Slido. ¿Tienes que iniciar la aplicación localmente para depurar pruebas? ¿Necesita Replay acceso al código fuente? ¿Qué es Replay? Para usar Replay en CI, dile a tu marco de pruebas que use el navegador Replay. Cada ejecución de prueba crea una grabación. Decide qué grabaciones subir y obtén una URL. Pon la URL en un comentario de PR. Abre las herramientas de desarrollo de Replay en cualquier navegador para depurar.
y luego dale el valor de antes. Sí. Eso ayuda. Gracias. Y luego, una vez más, siempre puedes hacer preguntas de seguimiento a través de Slido también. Entonces, sí. Creo que esto podría haberse respondido enmarcando Replay como un navegador, pero ¿tienes que iniciar la aplicación localmente? Hay algo sobre el flujo de trabajo, un montón de preguntas. Incluso la siguiente, se siente un poco así. ¿Tienes que iniciar la aplicación localmente para poder
debug pruebas? Y la siguiente es, ¿tiene Replay que tener acceso al código fuente? ¿Tienes que publicar el código fuente para usar Replay? Creo que todas estas están en el mismo ámbito de pregunta. ¿Qué es Replay? Alguien lo tiene. Sí. Entonces, para usar Replay, digamos en
CI, tienes que decirle a tu marco de pruebas que use el navegador Replay. Vale. No voy a usar Chrome. No voy a usar Firefox. Voy a usar Replay Chrome. Aquí está el navegador. Úsalo. Una vez que haces eso, cada vez que se ejecuta la prueba, va a crear una grabación. Entonces, se abre la pestaña del navegador, se cierra la pestaña del navegador, nuevo archivo de grabación. Cuando todas las pruebas se han ejecutado, tienes todas estas grabaciones en el disco. Decides cuáles quieres subir. Quizás solo quieras subir las que fallan. Realmente no me importa. Cuando lo subes, obtienes una URL. Ponemos esa URL en un comentario de PR. Es como, hey, tu prueba falló. ¿Quieres hacer clic? Haz clic. Entonces llegas a las herramientas de desarrollo de Replay. Eso es lo que te estaba mostrando. Pero eso significa que en cualquier navegador, Safari o Firefox o Chrome, puedes abrir las herramientas de desarrollo de Replay. Es
Navegador Replay y características de depuración
Replay es un navegador que captura interacciones con el sistema operativo subyacente, permitiéndote recopilar más información para la depuración. Funciona en tu máquina y se puede descargar desde replayo. Al hacer clic en grabar, guardar y obtener una URL, puedes ver la repetición con un navegador basado en la nube que habilita las características de depuración.
va a hablar con el
backend de Replay. Y en el
backend de Replay, tenemos miles de
Docker containers. Y cada contenedor
Docker tiene un navegador que piensa que está funcionando en el dispositivo original. Solo está reproduciendo. Esto es casi como inyectarte en un punto de este proceso donde normalmente irías a usar un navegador estándar, digamos. Y luego es capaz de espiar cada actividad que sucede dentro de esa prueba. Sí. Sí. Claro. Siento que, de nuevo, cubriste esto un poco, pero tiene muchos votos, así que quiero hablar de ello explícitamente. Si tuvieras que resumir, ¿cuáles son las ventajas de usar... Puedes añadir un registro de consola. Si miras el replay de
Cypress o el visor de trazas de Playwright o cualquier herramienta de
observability que exista, nunca te van a permitir pausar en una línea de código e inspeccionar el estado. Nunca podrás añadir un registro de consola en la línea 10 y ver los registros porque en realidad no están reproduciendo. Están capturando el DOM y mostrándote el
video elegante, lo cual es genial. Tiene valor en eso. Pero en realidad no está iniciando un navegador que pueda reproducir y pausar en una línea de código. ¿Podemos retroceder unos pasos sobre qué es Replay una vez más? Correcto. Así que es un navegador. Básicamente capturará todas las interacciones que se hagan con el sistema operativo subyacente, por lo que puedes capturar mucha más información y usarla como parte de tu práctica de depuración. Replay en sí mismo funciona en tu máquina. Lo descargas y lo ejecutas. Hay algo en eso que no está del todo claro. Replay también es un servicio y una empresa que necesita existir. Hay algo en eso que para mí, al menos, no está del todo claro en términos de conocimiento. Claro. Entonces, ¿cómo se configuraría Replay para un proyecto? Para simplificarlo, cualquiera puede ir a replayo, hacer clic en descargar y obtener el navegador Replay. Y cuando lo usas, hay un pequeño botón de grabar en la parte superior derecha. Haces clic en grabar, haces algunas cosas, haces clic en guardar, obtienes una URL y luego puedes ver esa repetición. Ahora cuando estás viendo esa repetición, hay un navegador en la
cloud que está reproduciendo esa sesión y permitiendo
Navegador Replay y Depuración Colaborativa
Replay es un navegador que puede reproducir y ofrece depuración retroactiva. Funciona en tu máquina y en la nube, permitiéndote compartir y guardar acciones de depuración con otros. Este enfoque colaborativo tiene como objetivo hacer la depuración más accesible e inclusiva. Aunque Replay se basa en Chromium con modificaciones menores, no puede capturar otros motores de renderizado.
realizas todas las funciones de depuración. Lo que significa es que obtienes la depuración retroactiva como parte de ese servicio. Pero en esencia, es un navegador que puede reproducir. Tenemos reproducción de los internos del sistema operativo del navegador, pero no piensas en eso. Piensas en términos de lo que está en el monitor de red. ¿Puedo agregar un registro de consola en 10? Ese tipo de cosas. Interesante. Creo que tiene sentido. Genial. Y realmente, el lado del servicio es el hecho de que también se ejecuta en la
cloud. Esa es la clave. Y en teoría, siguiendo con la siguiente pregunta, ¿puede Replay grabar también mis acciones de depuración para que pueda compartirlas y guardarlas con otros? Ahí es donde los comentarios son realmente útiles. Estás depurando, y dices, oh, esta línea es interesante, esta línea es interesante, esta línea es interesante. Genial. Deja algunos comentarios. Y luego puedes preguntarte, ¿qué estaba haciendo? Ah, eso es lo que estaba haciendo. Y también puedes compartir eso con otros. Y obviamente eso es parte del atractivo de tener un servicio que de alguna manera... Quiero decir, es un poco extraño que sea híbrido. Es como si se ejecutara en tu máquina, pero para realmente desbloquear el poder de ello en un entorno de equipo, también quieres que esté disponible. Lo veo como Figma. Hay muchos diseñadores antes de Figma que trabajaban en su propio archivo de Sketch o Photoshop. Pero cuando traes a Figma, entonces todo el equipo puede ser parte del proceso de
design. Para mí, pienso en todos los desarrolladores que están haciendo toda la depuración por sí mismos en una habitación oscura a las 2AM y es difícil. Y es muy agradable hacer que la depuración, que ha sido históricamente un jardín amurallado, puedes hacerlo, pero no puedes hacerlo con otros. Y solo las personas que pueden
debug durante mucho tiempo por sí mismos pueden convertirse en desarrolladores, haciendo eso también colaborativo.
Esta es una pregunta realmente interesante. Entonces, si Replay es su propio navegador, ¿no habrá también un problema de no trabajar exactamente en el mismo espacio que los usuarios? Quiero decir, es Chromium. Hemos hecho modificaciones menores.
Navegador Replay y Capacidades de Pruebas
Es un navegador Chromium, y estamos probando en el contexto de un navegador Chromium. Todo el tiempo de ejecución debería ser grabable. Venimos de Mozilla y comenzamos con Firefox. También tenemos un grabador de nodos para el backend. Python, Ruby, Java y Safari son grabables. Replay puede hacer pruebas de unidad y de componentes. Las pruebas de componentes se sentirían casi idénticas a lo que se mostró. Las DevTools de Replay pueden acceder al código de la aplicación incluso en pruebas de caja negra. Piensa en las DevTools de Replay como las DevTools de Chrome. Se necesitan mapas de origen, y estos pueden ser subidos a Sentry y otras herramientas para configuraciones de producción.
Genial. Pero, de nuevo, no es como si pudiera capturar otros motores de renderizado. Es un navegador Chromium, y estamos
testing en el contexto de un navegador Chromium. Creo que todo el runtime debería ser grabable. Así que venimos de Mozilla. Así que empezamos con Firefox. Chrome es bastante importante, así que estamos priorizando Chrome. Pero veo un futuro donde, quiero decir, también tenemos un grabador de nodos, también, para el
backend. Python, Ruby, Java, obviamente Safari, todos son grabables. Hay un montón de preguntas aquí que creo que podrían ser un poco más rápidas. ¿Puede Replay también hacer pruebas de unidad y de componentes
testing, o está principalmente enfocado en pruebas de extremo a extremo
testing? Claro. Puedes hacer pruebas de componentes
testing. ¿Sí? ¿Cómo se sentiría eso diferente a lo que nos mostraste hoy? Sería casi idéntico. ¿Sí? Si la prueba de componentes se ejecuta en el navegador, lo tienes. Si te estás enfocando en el nodo y estás usando un grabador de nodos, seguro, puedes hacer eso. Genial. Solo echando un vistazo muy rápido a algunas de las otras preguntas mientras tenemos solo un par de minutos más, ¿puede Replay acceder al código de la aplicación, incluso si estoy haciendo pruebas de caja negra
testing, lo que significa que no puedes acceder al código de la aplicación en sí? Porque creo que había algo interesante allí donde seguías volviendo al código. Pero supongo que ese es el código enviado, ese es un paquete que se envía. Así que piensa en las
DevTools de Replay como las
DevTools de Chrome
DevTools. No tienes que hacer nada para configurar las
DevTools de Chrome. Simplemente abres las
DevTools de Chrome, como, hey, puedo inspeccionar mi aplicación. Pero necesitas mapas de origen. Y la mayoría de los mapas de origen no se envían a producción. Como si estuvieras en desarrollo, tienes mapas de origen. Lo mismo con replay. Si estás usando replay y hay mapas de origen en
CI, estás bien. Nada que necesites hacer. Si usas replay en dev y hay mapas de origen, nada que necesites hacer. Si pides soporte para grabar el bug en producción o el soporte pide a un usuario realmente importante que quiere que se arregle el bug para grabar un replay, no tienes mapas de origen. Así que estás en problemas. Pero lo que la gente hace para solucionar esto es que suben sus mapas de origen a Sentry y otras herramientas. Así que los mapas de origen están disponibles en esa configuración de producción,
Integrando Replay en CI y Consideraciones de Costo
Si actualizas tu herramienta de construcción para que también suba a Replay, también tendrás mapas de origen. Para Cypress, es como npm install replay Cypress, lo añades a la configuración de Cypress, y listo. Para Selenium, descarga el navegador con anticipación, actualiza la configuración de web driver IO, la ruta del navegador, la ruta a tu Chromium de Replay, y listo. ¿Podrías usar Replay para probar una aplicación basada en Electron? Electron es como medio Node, medio Chrome. No tenemos una construcción de Electron, pero puedes imaginar que si tienes un grabador de Node y un grabador de Chrome, como, tenemos una construcción de Electron. ¿Replay funciona también en un modo sin cabeza? Sí, hacemos ambos. Es solo un navegador. Hablemos del costo de la parte de la nube del servicio y cómo contribuye a un negocio sostenible.
pero solo, como, para esos servicios. Si actualizas tu herramienta de construcción para que también suba a Replay, tendrás mapas de origen también. Genial. Entonces, sí, creo que solo la otra parte que no me cuadra del todo, también, es, como, ¿cómo integrarías Replay en un pipeline de
CI? Sí. Para
Cypress, es como
npm install replay
Cypress, lo añades a la configuración de
Cypress, y listo. Para Selenium, descarga el navegador con anticipación, actualiza, no sé, la configuración de web driver IO, la ruta del navegador, la ruta a tu Chromium de Replay, y listo. Una pregunta que acaba de llegar que es interesante, quiero tomar un momento para ello, ¿podrías usar Replay para
testing una aplicación basada en Electron? Así que no está estrictamente ejecutándose en el navegador, pero lo está. Quiero decir, ¿qué es Electron? Electron es, como, medio Node, medio Chrome. No tenemos una construcción de Electron, pero puedes imaginar que si tienes un grabador de Node y un grabador de Chrome, como, tenemos una construcción de Electron. Sí. Digamos que está en el mapa de ruta. Genial. Quiero decir, sí. Claro. ¿Replay funciona también en un modo
headless? Sí. Y por supuesto, eso es necesario para, como, ejecutarlo en entornos de
CI. Sí, hacemos ambos. Es solo un navegador. Voy a tomar solo un par de segundos. Tenemos solo un minuto más. Tenemos tantas preguntas. Literalmente, dame 10 segundos, voy a encontrar las que pasamos estos últimos momentos. ¿Puedo hacer la de costos? Sí, ahí tienes. Así que podría simplemente irme a casa. Podrías hacer esto. Adelante. Parece divertido. Claro. Así que ya hemos hablado brevemente sobre esa parte del
cloud del servicio siendo la clave para
Costo de Replay y Celebración
Replay es más barato de grabar que un video, y tiene menos sobrecarga en comparación con otras herramientas. Puedes elegir qué subir, reduciendo los costos. Únete a la celebración de la finalización de la masterclass.
un negocio sostenible. Costará dinero de alguna manera. Hablemos de eso. ¿Cómo funciona? Entonces, dos cosas sobre el costo. La primera es la sobrecarga. Lo realmente extraño acerca de Replay es que es más barato grabar un replay que grabar un
video. Entonces, cuando
Cypress tenía
Cypress video, eso agregó más sobrecarga que grabar un replay. El
video que está en nuestras herramientas de desarrollo de Replay, lo creamos después del hecho mientras estábamos jugando. Entonces, Replay es realmente barato cuando estás grabando en
CI desde la perspectiva de la sobrecarga. La segunda cosa es sobre el lado del costo, la mayoría de las herramientas dicen subir todo. Nosotros decimos sube las cosas que quieres. Y cuando subes solo como los cinco fallos para esta prueba y cinco fallos para esta prueba, etcétera, etcétera, es bastante razonable. Intentamos mantener el costo bastante bueno. Esa nunca ha sido una razón por la que la gente no ha usado Replay.
Genial. Por favor, únete a mí para darle a Jason un aplauso masivo y hazlo aún más grande porque esta masterclass se ha completado. Lo hicimos. Lo hicimos. Se acabó.
TestJS Summit 2021
