Deja de Clasificar Tu Suite de Pruebas

Rate this content
Bookmark

En algún momento, aceptamos que las pruebas de extremo a extremo serán inestables, está bien agregar reintentos y es una buena práctica poner en cuarentena las malas pruebas. ¡No tiene que ser así! Esta charla cubrirá las razones más comunes para las pruebas inestables, cómo depurarlas con un depurador de viaje en el tiempo y cómo solucionarlas. Si bien las pruebas inestables son un problema tan antiguo como las pruebas, resulta que cuando puedes capturarlas e inspeccionarlas con las DevTools del navegador y los registros de consola retroactivos, son bastante solucionables. Y una suite de pruebas libre de inestabilidades se ejecuta más rápido, de manera más confiable y ayuda a detectar más problemas antes de que lleguen a producción.

29 min
07 Dec, 2023

AI Generated Video Summary

Esta charla presenta Replay, una herramienta de desarrollo de navegador con capacidad de viaje en el tiempo para depurar suites de pruebas. Enfatiza la importancia de la colaboración entre los equipos de producto y QA para mantener y mejorar las suites de pruebas. La charla demuestra cómo se pueden usar las DevTools de Replay para depurar fallas en las pruebas y analizar la salud de la suite de pruebas. También destaca los beneficios de usar Replay para la reproducibilidad y la depuración colaborativa. Además, discute la integración de Replay en CI y las consideraciones de costos asociadas con el uso de la herramienta.

1. Introducción al Triaje de Suite de Pruebas

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

QnA

Uso de Replay para la depuración de pruebas

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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

Short description:

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ó.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
33 min
Network Requests with Cypress
Whether you're testing your UI or API, Cypress gives you all the tools needed to work with and manage network requests. This intermediate-level task demonstrates how to use the cy.request and cy.intercept commands to execute, spy on, and stub network requests while testing your application in the browser. Learn how the commands work as well as use cases for each, including best practices for testing and mocking your network requests.
TestJS Summit 2021TestJS Summit 2021
38 min
Testing Pyramid Makes Little Sense, What We Can Use Instead
Featured Video
The testing pyramid - the canonical shape of tests that defined what types of tests we need to write to make sure the app works - is ... obsolete. In this presentation, Roman Sandler and Gleb Bahmutov argue what the testing shape works better for today's web applications.
TestJS Summit 2022TestJS Summit 2022
27 min
Full-Circle Testing With Cypress
Cypress has taken the world by storm by brining an easy to use tool for end to end testing. It’s capabilities have proven to be be useful for creating stable tests for frontend applications. But end to end testing is just a small part of testing efforts. What about your API? What about your components? Well, in my talk I would like to show you how we can start with end-to-end tests, go deeper with component testing and then move up to testing our API, circ
TestJS Summit 2021TestJS Summit 2021
31 min
Test Effective Development
Developers want to sleep tight knowing they didn't break production. Companies want to be efficient in order to meet their customer needs faster and to gain competitive advantage sooner. We ALL want to be cost effective... or shall I say... TEST EFFECTIVE!But how do we do that?Are the "unit" and "integration" terminology serves us right?Or is it time for a change? When should we use either strategy to maximize our "test effectiveness"?In this talk I'll show you a brand new way to think about cost effective testing with new strategies and new testing terms!It’s time to go DEEPER!
TestJS Summit 2023TestJS Summit 2023
21 min
Everyone Can Easily Write Tests
Let’s take a look at how Playwright can help you get your end to end tests written with tools like Codegen that generate tests on user interaction. Let’s explore UI mode for a better developer experience and then go over some tips to make sure you don’t have flakey tests. Then let’s talk about how to get your tests up and running on CI, debugging on CI and scaling using shards.

Workshops on related topic

React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn
TestJS Summit 2022TestJS Summit 2022
146 min
How to Start With Cypress
Featured WorkshopFree
The web has evolved. Finally, testing has also. Cypress is a modern testing tool that answers the testing needs of modern web applications. It has been gaining a lot of traction in the last couple of years, gaining worldwide popularity. If you have been waiting to learn Cypress, wait no more! Filip Hric will guide you through the first steps on how to start using Cypress and set up a project on your own. The good news is, learning Cypress is incredibly easy. You'll write your first test in no time, and then you'll discover how to write a full end-to-end test for a modern web application. You'll learn the core concepts like retry-ability. Discover how to work and interact with your application and learn how to combine API and UI tests. Throughout this whole workshop, we will write code and do practical exercises. You will leave with a hands-on experience that you can translate to your own project.
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
WorkshopFree
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
TestJS Summit 2023TestJS Summit 2023
48 min
API Testing with Postman Workshop
WorkshopFree
In the ever-evolving landscape of software development, ensuring the reliability and functionality of APIs has become paramount. "API Testing with Postman" is a comprehensive workshop designed to equip participants with the knowledge and skills needed to excel in API testing using Postman, a powerful tool widely adopted by professionals in the field. This workshop delves into the fundamentals of API testing, progresses to advanced testing techniques, and explores automation, performance testing, and multi-protocol support, providing attendees with a holistic understanding of API testing with Postman.
1. Welcome to Postman- Explaining the Postman User Interface (UI)2. Workspace and Collections Collaboration- Understanding Workspaces and their role in collaboration- Exploring the concept of Collections for organizing and executing API requests3. Introduction to API Testing- Covering the basics of API testing and its significance4. Variable Management- Managing environment, global, and collection variables- Utilizing scripting snippets for dynamic data5. Building Testing Workflows- Creating effective testing workflows for comprehensive testing- Utilizing the Collection Runner for test execution- Introduction to Postbot for automated testing6. Advanced Testing- Contract Testing for ensuring API contracts- Using Mock Servers for effective testing- Maximizing productivity with Collection/Workspace templates- Integration Testing and Regression Testing strategies7. Automation with Postman- Leveraging the Postman CLI for automation- Scheduled Runs for regular testing- Integrating Postman into CI/CD pipelines8. Performance Testing- Demonstrating performance testing capabilities (showing the desktop client)- Synchronizing tests with VS Code for streamlined development9. Exploring Advanced Features - Working with Multiple Protocols: GraphQL, gRPC, and more
Join us for this workshop to unlock the full potential of Postman for API testing, streamline your testing processes, and enhance the quality and reliability of your software. Whether you're a beginner or an experienced tester, this workshop will equip you with the skills needed to excel in API testing with Postman.
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
WorkshopFree
This workshop will teach you the basics of writing useful end-to-end tests using Cypress Test Runner.
We will cover writing tests, covering every application feature, structuring tests, intercepting network requests, and setting up the backend data.
Anyone who knows JavaScript programming language and has NPM installed would be able to follow along.
TestJS Summit 2023TestJS Summit 2023
148 min
Best Practices for Writing and Debugging Cypress Tests
Workshop
You probably know the story. You’ve created a couple of tests, and since you are using Cypress, you’ve done this pretty quickly. Seems like nothing is stopping you, but then – failed test. It wasn’t the app, wasn’t an error, the test was… flaky? Well yes. Test design is important no matter what tool you will use, Cypress included. The good news is that Cypress has a couple of tools behind its belt that can help you out. Join me on my workshop, where I’ll guide you away from the valley of anti-patterns into the fields of evergreen, stable tests. We’ll talk about common mistakes when writing your test as well as debug and unveil underlying problems. All with the goal of avoiding flakiness, and designing stable test.