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.
This talk has been presented at TestJS Summit 2023, check out the latest edition of this JavaScript Conference.
FAQ
Replay es una herramienta de desarrollo de navegador con capacidad de viaje en el tiempo, que permite a los desarrolladores depurar aplicaciones como si estuvieran funcionando en vivo. Funciona capturando todas las interacciones con el sistema operativo, permitiendo reproducir y depurar el comportamiento exacto de las pruebas en cualquier momento.
A medida que las empresas crecen, las pruebas se vuelven más difíciles debido a la inestabilidad generada por mayores volúmenes de código de aplicación y backend. Incluso grandes empresas como Facebook, Apple y Google enfrentan dificultades para mantener pruebas estables.
Replay permite a los equipos de desarrollo depurar pruebas de navegador registrando las sesiones de prueba, lo que facilita identificar y corregir errores que ocurren esporádicamente y solo en ciertos entornos, como los de integración continua (CI).
No es necesario tener acceso al código fuente para utilizar Replay, pero tener los mapas de origen facilita la depuración al permitir correlacionar el código ejecutado con el código fuente correspondiente.
Replay ofrece una nueva forma de colaborar en la depuración de pruebas de navegador, permitiendo a los equipos compartir y revisar sesiones de pruebas detalladamente. Esto puede ayudar a mejorar la calidad de las pruebas y la eficiencia de los equipos de QA.
Sí, Replay también puede utilizarse para pruebas de componentes y pruebas de backend, siempre que estas se ejecuten en un entorno que pueda ser grabado por Replay, como Node.js para backend.
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.
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ó.
Cecilia Martinez, a technical account manager at Cypress, discusses network requests in Cypress and demonstrates commands like cydot request and SCI.INTERCEPT. She also explains dynamic matching and aliasing, network stubbing, and the pros and cons of using real server responses versus stubbing. The talk covers logging request responses, testing front-end and backend API, handling list length and DOM traversal, lazy loading, and provides resources for beginners to learn Cypress.
Testing Pyramid Makes Little Sense, What We Can Use Instead
Top Content
Featured Video
2 authors
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.
Cypress is a powerful tool for end-to-end testing and API testing. It provides instant feedback on test errors and allows tests to be run inside the browser. Cypress enables testing at both the application and network layers, making it easier to reach different edge cases. With features like AppActions and component testing, Cypress allows for comprehensive testing of individual components and the entire application. Join the workshops to learn more about full circle testing with Cypress.
This Talk introduces Test Effective Development, a new approach to testing that aims to make companies more cost-effective. The speaker shares their personal journey of improving code quality and reducing bugs through smarter testing strategies. They discuss the importance of finding a balance between testing confidence and efficiency and introduce the concepts of isolated and integrated testing. The speaker also suggests different testing strategies based on the size of the application and emphasizes the need to choose cost-effective testing approaches based on the specific project requirements.
The Playwright Test Runner is a cross-browser web testing framework that allows you to write tests using just a few lines of code. It supports features like parallel test execution, device emulation, and different reporters for customized output. Code-Gen is a new feature that generates code to interact with web pages. Playwright Tracing provides a powerful tool for debugging and analyzing test actions, with the ability to explore trace files using TraceViewer. Overall, Playwright Test offers installation, test authoring, debugging, and post-mortem debugging capabilities.
Playwright is a reliable end-to-end testing tool for modern web apps that provides one API, full isolation, fast execution, and supports multiple languages. It offers features like auto-weighting, retrying assertions, seamless testing of iframes and shadow DOM, test isolation, parallelism, and scalability. Playwright provides tools like VS Code extension, UiMode, and Trace Viewer for writing, debugging, and running tests. Effective tests prioritize user-facing attributes, use playwright locators and assertions, and avoid testing third-party dependencies. Playwright simplifies testing by generating tests, providing code generation and UI mode, and allows for easy running and debugging of tests. It helps in fixing failed tests and analyzing DOM changes, fixing locator mismatches, and scaling tests. Playwright is open source, free, and continuously growing.
La Biblioteca de Pruebas de React es un gran marco para las pruebas de componentes de React porque responde muchas preguntas por ti, por lo que no necesitas preocuparte por esas preguntas. Pero eso no significa que las pruebas sean fáciles. Todavía hay muchas preguntas que tienes que resolver por ti mismo: ¿Cuántas pruebas de componentes debes escribir vs pruebas de extremo a extremo o pruebas de unidad de nivel inferior? ¿Cómo puedes probar una cierta línea de código que es difícil de probar? ¿Y qué se supone que debes hacer con esa persistente advertencia de act()? En esta masterclass de tres horas, presentaremos la Biblioteca de Pruebas de React junto con un modelo mental de cómo pensar en el diseño de tus pruebas de componentes. Este modelo mental te ayudará a ver cómo probar cada bit de lógica, si debes o no simular dependencias, y ayudará a mejorar el diseño de tus componentes. Te irás con las herramientas, técnicas y principios que necesitas para implementar pruebas de componentes de bajo costo y alto valor. Tabla de contenidos- Los diferentes tipos de pruebas de aplicaciones de React, y dónde encajan las pruebas de componentes- Un modelo mental para pensar en las entradas y salidas de los componentes que pruebas- Opciones para seleccionar elementos DOM para verificar e interactuar con ellos- El valor de los mocks y por qué no deben evitarse- Los desafíos con la asincronía en las pruebas de RTL y cómo manejarlos Requisitos previos- Familiaridad con la construcción de aplicaciones con React- Experiencia básica escribiendo pruebas automatizadas con Jest u otro marco de pruebas unitarias- No necesitas ninguna experiencia con la Biblioteca de Pruebas de React- Configuración de la máquina: Node LTS, Yarn
La web ha evolucionado. Finalmente, también lo ha hecho el testing. Cypress es una herramienta de testing moderna que responde a las necesidades de testing de las aplicaciones web modernas. Ha ganado mucha popularidad en los últimos años, obteniendo reconocimiento a nivel mundial. Si has estado esperando aprender Cypress, ¡no esperes más! Filip Hric te guiará a través de los primeros pasos sobre cómo empezar a usar Cypress y configurar tu propio proyecto. La buena noticia es que aprender Cypress es increíblemente fácil. Escribirás tu primer test en poco tiempo y luego descubrirás cómo escribir un test de extremo a extremo completo para una aplicación web moderna. Aprenderás conceptos fundamentales como la capacidad de reintentar. Descubre cómo trabajar e interactuar con tu aplicación y aprende cómo combinar pruebas de API y de UI. A lo largo de todo este masterclass, escribiremos código y realizaremos ejercicios prácticos. Saldrás con una experiencia práctica que podrás aplicar a tu propio proyecto.
A diferencia de las pruebas unitarias, las pruebas de extremo a extremo buscan interactuar con su aplicación tal como lo haría un usuario real. Y como todos sabemos, puede ser bastante desafiante. Especialmente cuando hablamos de aplicaciones móviles. Las pruebas dependen de muchas condiciones y se consideran lentas e inestables. Por otro lado, las pruebas de extremo a extremo pueden dar la mayor confianza de que su aplicación está funcionando. Y si se hace correctamente, puede convertirse en una herramienta increíble para aumentar la velocidad del desarrollador. Detox es un marco de pruebas de extremo a extremo en caja gris para aplicaciones móviles. Desarrollado por Wix para resolver el problema de la lentitud e inestabilidad y utilizado por React Native en sí como su herramienta de pruebas E2E. Únete a mí en esta masterclass para aprender cómo hacer que tus pruebas de extremo a extremo móviles con Detox sean excelentes. Prerrequisitos- iOS/Android: MacOS Catalina o más reciente- Solo Android: Linux- Instalar antes de la masterclass
En el panorama siempre en evolución del desarrollo de software, garantizar la fiabilidad y funcionalidad de las API se ha vuelto primordial. "Pruebas de API con Postman" es una masterclass completa diseñada para equipar a los participantes con los conocimientos y habilidades necesarios para sobresalir en las pruebas de API utilizando Postman, una herramienta poderosa ampliamente adoptada por profesionales en el campo. Esta masterclass profundiza en los fundamentos de las pruebas de API, avanza a técnicas de prueba avanzadas y explora la automatización, las pruebas de rendimiento y el soporte multiprotocolo, proporcionando a los asistentes una comprensión holística de las pruebas de API con Postman. Únete a nosotros para esta masterclass para desbloquear todo el potencial de Postman para las pruebas de API, agilizar tus procesos de prueba y mejorar la calidad y fiabilidad de tu software. Ya seas un principiante o un probador experimentado, esta masterclass te equipará con las habilidades necesarias para sobresalir en las pruebas de API con Postman.
Si encontrar errores en tu proyecto frontend es como buscar una aguja en un pajar de código, entonces el monitoreo de errores de Sentry puede ser tu detector de metales. Aprende los conceptos básicos del monitoreo de errores con Sentry. Ya sea que estés ejecutando un proyecto de React, Angular, Vue, o simplemente JavaScript “vainilla”, mira cómo Sentry puede ayudarte a encontrar el quién, qué, cuándo y dónde detrás de los errores en tu proyecto frontend. Nivel de la masterclass: Intermedio
Este masterclass te enseñará los conceptos básicos de cómo escribir pruebas de extremo a extremo utilizando Cypress Test Runner. Cubriremos la escritura de pruebas, abarcando todas las características de la aplicación, estructurando las pruebas, interceptando solicitudes de red y configurando los datos del backend. Cualquier persona que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir el masterclass.
Comments