Pruebas predictivas en JavaScript con Machine Learning

Hola a todos, bienvenidos a TestJS Summit 2021 y soy Shivaay, quien presentará un tema sobre las pruebas predictivas en JavaScript con aprendizaje automático. Una breve introducción sobre mí, soy Shivaay y actualmente soy miembro del grupo de trabajo de TensorFlow.JS. Soy mentor de código del servidor de Google en TensorFlow y esta es mi tercera conferencia de GitNation este año. Anteriormente, también di una charla en la conferencia de Node.js y también en React Advanced este año. Estoy muy emocionado de presentar otra charla en GitNation, específicamente en TestJS Summit. Así que sin perder más tiempo, ¡comencemos!

Ahora, primero, el aprendizaje automático está realmente en todas partes hoy en día. No hay duda al respecto. Se puede ver que el aprendizaje automático se utiliza en la atención médica, la educación, pero también en el desarrollo de software en sí. Hoy en día, el aprendizaje automático se utiliza para hacer muchas cosas diferentes. Por ejemplo, hemos visto cómo GitHub Copilot se utiliza hoy en día para generar automáticamente o sugerir nuevo código. También se utiliza en MLOps, en diferentes formas de operaciones en DevOps para mejorar los ciclos de DevOps. Y eso hace que sea realmente importante también usarlo en otras áreas donde tradicionalmente no pensaríamos que se podría utilizar. Entonces, eso es lo que hace que el aprendizaje automático sea realmente poderoso hoy en día. Y por eso, ¿por qué no pensar en introducir el aprendizaje automático en las pruebas de software?

Las pruebas de software tradicionalmente se han centrado en poder escribir casos de prueba, poder comprender fundamentalmente dentro de todo el ciclo de vida de la ingeniería de software cómo podemos hacer que nuestros software sean cada vez más productivos y libres de errores. Eso significa que idealmente, si tienes un probador de software o un analista de control de calidad, revisarán todo el código y escribirán casos de prueba unitarios. Y, por supuesto, tenemos todo el proceso de cómo comienza realmente la prueba, donde primero escribimos algo de código, luego preparamos las pruebas unitarias, tenemos pruebas de integración. Y en función de esto, una vez que los casos de prueba se aprueban y nuestro código pasa por todos estos diferentes casos de prueba tanto de la unidad como de la integración, finalmente ponemos nuestro código en producción. También utilizamos cosas como pruebas de regresión para ver cómo el nuevo código está afectando el código que se ha escrito anteriormente o, digamos, algunas de las bases de código antiguas y cómo se está viendo afectado este código. Todos estos procesos implican básicamente que puedes usar pruebas manuales o también tienes muchas herramientas de pruebas de automatización diferentes, como Selenium. Y tradicionalmente, estas no han utilizado realmente el aprendizaje automático. Tiene más que ver con escribir estos casos de prueba si estás haciendo pruebas manuales o incluso si estás utilizando herramientas de pruebas de automatización como Selenium para poder configurarlas para que puedan pasar por tu aplicación. Y en general, las pruebas de software realmente no han visto mucho uso de la IA, pero esta charla específicamente hablará sobre cómo podemos introducir y cuáles son los beneficios de agregar el aprendizaje automático o la IA a las pruebas de software.

Entonces, escribamos sobre algunos de los grandes escenarios donde la IA podría ser utilizada en las pruebas. El primero es la generación automatizada de casos de prueba. Muchas veces, pasamos mucho tiempo creando casos de prueba. Eso podría ser programación orientada al comportamiento o desarrollo orientado al comportamiento, donde creamos los casos de prueba antes de escribir el código en sí, o digamos que hemos escrito una función en particular y escribimos un caso de prueba unitario para ella. ¿Cómo podemos usar la IA para generar casos de prueba sobre la marcha evaluando simplemente el código, revisando el código? Donde un modelo de IA simplemente comprende el código que se ha escrito, los cambios de código que se han realizado y luego genera automáticamente casos de prueba sin ninguna intervención manual. Luego, ser capaz de descubrir qué pruebas particulares se deben ejecutar realmente y que son más importantes, lo que ahorrará tiempo y el proceso completo del tiempo de prueba de software, donde solo estamos ejecutando los casos de prueba más importantes. También entraré en discusiones más profundas específicamente sobre el segundo punto y luego cómo podemos usar el aprendizaje automático no solo para probar la interfaz de usuario basada en frontend específicamente en JavaScript, sino también cómo podemos usar el aprendizaje automático para probar las API del backend. Eso también es uno de los campos donde actualmente se están desarrollando muchas herramientas de pruebas de software basadas en IA. Y luego, ¿cómo podemos lograr una cobertura de código del 100% con la ayuda de la IA? Porque la cobertura de código es un tema realmente importante que se utiliza cuando evaluamos cualquier tipo de base de código, cuando, digamos, creamos una nueva compilación o probamos nuevos despliegues, nuevos cambios que se han realizado. Si podemos lograr incluso un 90% o un 95% de cobertura de código, eso en sí mismo se considera un punto realmente excelente. Pero, ¿cómo podemos lograr una cobertura de código cercana al 100% con la ayuda de la IA? Y eso es algo en lo que la IA realmente puede ayudar, debido al hecho de que podemos evaluar el código con la ayuda de la IA y podemos generar pruebas automatizadas, podemos ejecutar las pruebas más importantes que son realmente importantes para ese cambio de código en particular, y eso ayudará a comprender todas las diferentes sutilezas del código que existen, incluidos los cambios de código y cómo los nuevos cambios han afectado realmente su código anterior. Todo eso se puede tener en cuenta al intentar lograr una cobertura de código con la ayuda de la IA. Y luego, incluso dentro del marco de pruebas de automatización, ¿cómo podemos usar realmente la IA, o digamos, con respecto a Selenium, para que cuando estemos haciendo cualquier tipo de prueba automatizada, la IA pueda ayudar a mejorarla al analizar específicamente los problemas que pueden surgir, y estamos utilizando una prueba manual, básicamente estamos utilizando pruebas de automatización para buscar específicamente esos problemas particulares y tratar de resolverlos. Estos son algunos de los escenarios en los que la IA se está utilizando actualmente en las pruebas de software.

Entonces, tenemos muchos softwares diferentes que utilizan IA para automatizar la generación de pruebas, utilizar el aprendizaje automático para mejorar las pruebas de regresión, utilizar el aprendizaje automático para obtener mejores predicciones en las pruebas de automatización, y estas soluciones gradualmente reemplazarán las pruebas de automatización basadas en Selenium, y por supuesto, la idea ahora es lograr una cobertura de código del 100% con la ayuda de la IA. Algunos de los beneficios que la IA proporcionará a las pruebas de software son, en primer lugar, ayuda a ahorrar tiempo. Ya sea al generar casos de prueba automatizados, lo cual ahorra mucho tiempo para los QA, o para aquellos que tenían que escribir los casos de prueba inicialmente, ayuda a ampliar el alcance de las pruebas. Ahora no se limita a probar solo los cambios entrantes, las pruebas de regresión o los cambios que se han realizado en el código y cómo han afectado a los cambios anteriores, también se encarga, con la ayuda de algoritmos relevantes basados en IA, de hacer que sea mucho más fácil de usar estos casos de prueba generados automáticamente o probados automáticamente proporcionados por la IA, lo que hace que el proceso general de las pruebas sea realmente simple y amplía el alcance para buscar este tipo de casos de prueba que los humanos o los probadores de software podrían olvidar, por lo que proporciona

La prevalencia de esos casos de prueba en particular también. Ahora veamos más de cerca cómo se ve realmente la prueba tradicional. Entonces, si hablamos de las pruebas de regresión, ahora las pruebas de regresión generalmente utilizarán cualquier información que se extraiga de una compilación que estamos creando, por lo que cada vez que se crea una compilación, tendremos ciertos metadatos con ella y podremos extraer información de ella para comprender qué prueba en particular se ejecutará en algún tipo de cambio de código que realmente ha tenido lugar. Y al analizar todos esos diferentes tipos de información que se ha proporcionado o se ha extraído de los metadatos de la compilación, uno puede determinar qué prueba en particular se debe realizar en el código cambiado o en cualquier cambio de código que haya tenido lugar, cuáles son las pruebas particulares que se deben realizar. Y digamos que una de las desventajas de esta suite de pruebas en particular sería que, digamos que si tuvieras que hacer un cambio en una de las bibliotecas de bajo nivel, en realidad sería ineficiente volver a ejecutar todas las pruebas juntas. Entonces, por ejemplo, incluso para equipos más pequeños, es posible que se le solicite que vuelva a ejecutar todos sus casos de prueba una y otra vez. Entonces, ahí es donde y, por supuesto, este diagrama es el mismo que tienes tus archivos fuente y tienes tus conjuntos de pruebas y hay ciertos cambios pequeños que ocurren. Luego, en función de esos cambios en una biblioteca en particular o en una llamada de red en particular o en una llamada de función en particular que estás haciendo, deberás volver a ejecutar esos casos de prueba una y otra vez. Y ahí es básicamente donde podemos usar el aprendizaje automático para hacer pruebas predictivas. Eso, esencialmente, ser capaz de encontrar cuál es la probabilidad de que si estás probando una prueba en particular, cómo podrás encontrar una regresión dentro de cualquier tipo de cambio de código que estemos haciendo. Entonces, ¿cómo podemos tomar decisiones informadas para descartar las pruebas que no serán útiles? Entonces, básicamente, ser capaz de seleccionar esas pruebas particulares que realmente importarán para ese cambio de código en particular porque, por supuesto, no todos los casos de prueba se comportarán o podrán descubrir problemas dentro de un cambio de código en particular. Por lo tanto, ser capaz de seleccionar inteligentemente esos cambios de código particulares que darán como resultado un proceso de prueba realmente mejor y realmente más rápido porque no estamos utilizando todos los diferentes casos de prueba para un cambio de código en particular. Entonces, básicamente, ¿cómo podemos lograr esto? Podríamos usar un gran conjunto de datos de cambios históricos de código, y luego, aplicando algoritmos de aprendizaje automático, podremos determinar qué pruebas particulares son más adecuadas para un tipo particular de cambios de código. Y eso nos permitirá en el futuro, antes de que realmente comience el proceso de prueba, o antes de que recibamos los cambios de código, podremos, antes de que comience el proceso de prueba, seleccionar solo aquellos casos de prueba particulares que sean más relevantes para esos tipos particulares de cambios de código. Y este tipo de diagrama muestra cómo realmente pretendemos lograr eso. Durante el proceso de entrenamiento, tenemos todos nuestros cambios de código históricos, por lo que esto se puede considerar como la base de datos para poder obtener estos cambios de código históricos y luego estamos utilizando nuestras pruebas. Y luego, básicamente, veremos si cada prueba fue un fallo o un éxito. Y luego podremos usarlo dentro de nuestro modelo de selección de pruebas. Y una vez que realmente comenzamos con la predicción, cada vez que tenemos algún tipo de cambio de código nuevo, básicamente usaremos nuestro modelo de selección de pruebas para ver qué prueba en particular podría ser realmente útil para ese cambio de código específico, y eso nos permitirá ahorrar tiempo. Y para hablar específicamente más sobre el proceso de entrenamiento. Entonces, vamos a tomar un modelo que básicamente solo aprende y las características que se derivan, ¿verdad? Entonces, cuando estamos haciendo la ingeniería de características, esencialmente estamos obteniendo todas esas de los cambios de código anteriores y las pruebas que se han ejecutado históricamente. Y cada vez que aplicamos este sistema en particular a cualquier tipo de cambio nuevo, esencialmente el modelo aprendido podrá aplicarse a ese cambio de código en particular. Y el modelo podrá predecir cuál es la probabilidad de detectar una regresión. Y en función de esta estimación en particular, podremos seleccionar aquellos casos de prueba particulares que tienen más probabilidades de cubrir ese cambio de código en particular. Entonces, así es como puedes ahorrar la cantidad de tiempo que realmente podría llevar generar el código. Esto se puede usar directamente con cualquier tipo de marco de pruebas basado en JavaScript, incluidas cosas como Jest, tenemos Jasmine, ¿verdad? Y, por supuesto, todos los diferentes marcos de pruebas diferentes también se pueden usar durante el ciclo de DevOps cuando realmente estamos usando, porque esto no se limita solo a la parte frontal de la codificación del backend, sino que básicamente se encuentra bajo el paraguas de las pruebas de operaciones. Entonces, durante el tiempo en el que estás construyendo o creando una compilación de tu aplicación o creando, digamos compilaciones y estás probando la aplicación para implementarla en producción, ahí es donde también podrías usar las pruebas predictivas. Y, por supuesto, incluso para JavaScript, por supuesto, podemos usar este tipo de sistema basado en aprendizaje automático donde seleccionas las pruebas más apropiadas. Pero incluso dentro de JavaScript, podemos tener una integración mucho mejor con diferentes marcos de pruebas que acabo de compartir. Y, por supuesto, también tenemos muchas acciones diferentes, por ejemplo, por PolyCode, que realmente ayudan a la generación automatizada de casos de prueba unitarios. Y también está disponible

Así que eso es prácticamente todo para esta charla. Espero que te haya gustado y hayas comprendido algunos conceptos nuevos. Si aún tienes alguna pregunta, estaré aquí para responder cualquier pregunta en la sesión de preguntas y respuestas. También puedes conectarte conmigo más tarde en mi Twitter en Heartvalue o en mi GitHub en theShivaLamba. Eso es todo de mi parte en SDS Summit. Muchas gracias por ver. Y espero ver a todos en el SDS Summit del próximo año. Muchas gracias. ¿Cómo estás? Sí, estoy bien. ¿Y tú? Es genial ver a tanta gente participando en el SDS Summit. Mi tema es un poco más único, pero me encantaría compartirlo contigo y responder algunas preguntas también. Muchas gracias. Sí, claro. Primero echemos un vistazo a los resultados de la encuesta. ¿Tuviste la oportunidad de verlos? ¿Qué opinas de los resultados? Me sorprendió un poco que nadie respondiera.

Están utilizando herramientas de IA para automatizar sus tareas. ¿Qué opinas al respecto? Sí, especialmente porque el título del tema era, ya sabes, utilizar IA para ayudar con los procesos de prueba. Y sí, no es realmente sorprendente, porque muchas de estas herramientas de prueba basadas en IA están en sus estados iniciales, no están bien establecidas, como otras herramientas realmente excelentes. Por ejemplo, si hablamos de JavaScript, algo como Cypress, ¿verdad? O digamos, Jest. Estas no son herramientas que están siendo utilizadas por cientos y miles de desarrolladores. Todavía están en una fase de crecimiento, pero ahora estamos viendo algunos casos de uso del mundo real de la prueba basada en IA. Y eso es lo que también intenté cubrir con algunos ejemplos en mi charla. Pero, por supuesto, al ver los resultados, vemos que muchas empresas dependen de tener probadores de calidad y probadores de software dedicados. Así que no confiamos realmente en los desarrolladores de software, sino que estos probadores de calidad y probadores de software trabajan con los desarrolladores de software para garantizar que estemos creando no solo desarrollo, sino realmente un desarrollo impulsado por pruebas, ¿verdad? Eso es hacia lo que muchas empresas se están enfocando actualmente. Sí, eso también fue impresionante. La mayoría todavía cuenta con probadores dedicados. Entonces, echemos un vistazo a algunas preguntas ahora. La primera es de AIUSA. Hola, el aprendizaje automático necesita datos para aprender. ¿Cómo podemos aplicar la generación automática de casos de prueba para nuevos productos/proyectos? Bueno, verás, me gustaría responder esto de dos maneras. La primera es que, como mencionaste, el aprendizaje automático definitivamente requiere conjuntos de datos. Durante el tiempo en que hablaba de la integración y la prueba de regresión, mencioné que lo que estamos haciendo es mirar los casos de prueba históricos que se escribieron para muchos tipos diferentes de código. Y esto es exactamente cómo se construyó GitHub co-pilot. Hoy en día estamos viendo el surgimiento de GitHub co-pilot, y sugiere código, escribes un comentario y te dará un ejemplo de código completo. Y cómo se entrenó fue también mirando todos los repositorios de código abierto que existían en GitHub. Y se entrenó en diferentes tipos de lenguajes y escenarios que están presentes. Entonces, de manera similar, lo que estamos haciendo en el caso de la prueba de software también es que estamos mirando cambios de código históricos y el tipo de casos de prueba que se aplican a esos cambios de código específicos. A través de esto, pudimos descubrir que, si tenemos un cambio de código en particular, por ejemplo, digamos que tenemos un archivo JavaScript y estamos construyendo una aplicación React, y hacemos algunos cambios en uno de los componentes de React. Digamos que está más enfocado en los enlaces, como estamos usando React Router, estamos usando algunos enlaces. Entonces, si ya sabemos que, para este tipo particular de cambios, podríamos tener casos de prueba específicos que se centran más en esos cambios de código específicos. Si podemos evaluar eso, ahorraremos mucho tiempo al eliminar la redundancia que implica crear casos de prueba que pueden no ser relevantes para ese cambio de código en particular. Entonces, en ese caso, si podemos aprender con la ayuda de cambios de código históricos, eso realmente se puede usar para generar código o generar casos de prueba que estén muy específicamente dedicados. Entonces, si la máquina es consciente de que el único cambio que hice es en una parte específica del código, y hemos entrenado a esa máquina para comprender que, para ese cambio de código específico, el código que se puede generar o el caso de prueba que se puede generar se utilizará solo para ese cambio de código en particular. Podremos crear casos de prueba muy específicos y ahorrar mucho tiempo.

Me pregunto si podríamos llegar a un punto en el que la máquina no solo analice el código base y los cambios y vea qué debe agregarse en términos de testing, sino también qué debe eliminarse. ¿Alguna vez lo has pensado? Como, ¿casos de prueba que ya no son válidos, sabes? Exactamente. Eso tiene mucho sentido. Digamos que hemos llegado a esa parte de nuestro ciclo de código donde algunos de los cambios de código, algunos de los casos de prueba pueden haberse vuelto redundantes y probablemente no los hayamos usado durante mucho tiempo. Entonces puede sugerirlo. Es algo que personalmente no he investigado, pero definitivamente es un buen proceso de pensamiento a considerar. Definitivamente. De acuerdo. Genial. Tenemos otra pregunta aquí de Mark Michaelis sobre cómo responder al cambio, que sería cómo la IA manejaría los fallos esperados porque el comportamiento cambió intencionalmente. Bueno, sí, supongo que esta es una pregunta realmente buena. Y nuevamente, lo que sucede es que cuando hablamos del comportamiento. Ahora el comportamiento, al menos lo que asumo de esta pregunta en particular, es que si estamos haciendo un cambio de código en particular y ahora digamos que una vez que hemos realizado un cambio de código en particular, queremos que la IA vea, okay, para este cambio de código en particular, ¿qué caso de prueba esperado podríamos ejecutar, pero digamos intencionalmente, si alguien está cambiando el código y la IA no ha pasado realmente por esa escena de código en particular, ¿verdad? Entonces no ha sido entrenada de esa manera. Entonces, en ese caso, lo que podemos hacer es, quiero decir, también habrá un grado de autoaprendizaje involucrado, a medida que le demos más y más casos de prueba más nuevos para que los analice, o, ya sabes, incluso con la IA, siempre tenemos ese tipo de escenarios en los que hay algún tipo de casos límite, que podrían hacer que la IA falle. Entonces, la respuesta esperada allí sería que proporcionemos un escenario adecuado de informe de errores y simplemente ayudemos a la IA a entrenar también con ese tipo de casos de prueba. Tiene mucho sentido. Y como dijiste, al principio, es algo que no está tan maduro como otros tipos de técnicas. Entonces tenemos que enseñarle a la máquina para que pueda absorber más por nosotros, los profesionales, para que pueda ayudarnos más en el futuro, ¿verdad? Sí, tenemos otra pregunta aquí de Carlos R, ¿tienes alguna otra métrica además de la cobertura de código? Por mi experiencia, incluso una cobertura de casi el 100% no garantiza que el producto esté realmente bien probado. Y estoy totalmente de acuerdo con Carlos R. Sí, absolutamente. Nuevamente, una pregunta realmente buena. Y mira, quiero decir, si consideramos cómo la IA puede ayudarte a alcanzar una cobertura de código del 200%, lo otro que sugeriría es que, aparte de ayudarte a alcanzar una cobertura de código del 200%, como mencioné, con la ayuda de la IA, lo que realmente estamos tratando de hacer es ahorrar tiempo a los probadores. Entonces, en lugar de escribir casos de prueba manuales una y otra vez, si solo obtienes una lista de casos de prueba unitarios sugeridos, o incluso si solo obtienes sugerencias de que, okay, para este cambio de código en particular que has hecho, este podría ser un buen caso de prueba que puedes agregar. Entonces, lo que la IA está haciendo aquí no es solo generar los casos de prueba para ti, sino que al mismo tiempo también está tratando de analizar esos casos en los que un humano podría pasar por alto. Por ejemplo, un QA o un desarrollador de software, un probador de software está mirando okay, ¿qué casos de prueba debo escribir? La IA podría sugerirte casos potenciales que probablemente pasarías por alto o que se te olvidarían. Esa podría ser otra métrica a considerar. Sí, creo que tiene mucho sentido. Ayer en la charla de Vlad con Ramon, creo que era, o no recuerdo exactamente su nombre, pero mencionaron otras cosas, no solo se trata, por ejemplo, del tiempo de ejecución, sino de cómo facilita y acelera la escritura y el mantenimiento de las tareas. Así que creo que sí, la IA puede ayudar mucho en eso.

Aquí es donde también quiero compartir nuevamente sobre Pony code. Sí, porque como mencioné, lo mencioné brevemente en una de mis diapositivas. Pony code es una de esas plataformas que básicamente es una herramienta construida para JavaScript y TypeScript. Y lo que hace es que analiza una de las funciones que has escrito. Por ejemplo, tienes como nodes.js y has creado una función simple y has utilizado module.export, ¿verdad? Entonces analizará la función y luego entenderá, okay, cuál es el contexto de esa función en particular y te ayudará a generar automáticamente algunos casos de prueba como pruebas unitarias. Te sugerirá y luego puedes, ya sabes, seleccionar los que sean relevantes para tu caso. No te obligamos a que te los dé directamente, sino que te da sugerencias para que las revises, que okay, estos son posibles casos de prueba que podrías tener. Sí, me gusta verlo como cuando hacemos programación en pareja, como el Nopilot u otra herramienta, es como si fueras un par y te está dando sugerencias, puedes

aceptarlos o no. Así que tenemos otra pregunta aquí de Omig, está viva. Martijn, un poco de abogado del diablo, si la IA puede escribir automáticamente los scripts para encontrar el error, ¿no deberíamos programar la IA para corregir el error de inmediato? Esa es una buena pregunta. Esa es una pregunta realmente buena. Sí, absolutamente. Supongo que aquí es donde, ya sabes, GitHub Copilot realmente lo está haciendo, ¿verdad? En caso de que quieras escribir una pregunta, quiero decir, escribes un comentario y GitHub Copilot ya te da una sugerencia para el código. Entonces de alguna manera podrías decir que sí, que se ha programado de tal manera que ayuda a autocompletar parte de tu código o te ayuda, ya sabes, a escribir la parte restante del código. Entonces, por ejemplo, digamos que te has encontrado con un error particular en tu código, y luego puedes ver la solución proporcionada por Copilot. Así que definitivamente, eso tiene sentido, que si también podemos crear algún tipo de scripts que te ayuden a corregir errores.

Definitivamente. Increíble. Estoy completamente de acuerdo. Tenemos otra pregunta aquí de Jay Munro. ¿Esto es principalmente para pruebas de interfaz de usuario de bajo nivel o posiblemente para la capa de integración? No está claro si esto sería efectivo para pruebas de extremo a extremo o pruebas de front-end. Tengo que decir que he utilizado GitHub Copilot para escribir pruebas de Cypress. A veces sabe exactamente lo que quiero, así que esa es mi opinión. Pero me encantaría escuchar la tuya, Shubhai.

Definitivamente. Una vez más, una pregunta realmente buena. Aquí es donde quiero decir que definitivamente puedes usarlo para pruebas de extremo a extremo. Ya sea que lo estés utilizando para pruebas de interfaz de usuario basadas en el navegador, hay herramientas que están surgiendo que realmente entienden cómo interactúa el navegador. Ya sea que estés probando diferentes tipos de componentes de React y cómo se comportan actualmente en el front-end, definitivamente puedes usarlo allí también. Entonces, podrías usarlo para hacer que las pruebas de automatización, digamos, usando Selenium u otras herramientas, sean más eficientes. Realmente puede ayudarte con las pruebas de extremo a extremo. Actualmente, lo estamos viendo más en el lado de menor nivel, que ayuda con los casos de prueba unitarios. Pero actualmente se están desarrollando herramientas que ayudarán no solo con los casos de prueba unitarios, sino también con pruebas basadas en el navegador, pruebas de interfaz de usuario o incluso pruebas de regresión. Por lo tanto, definitivamente se están creando herramientas para cubrir todos los aspectos posibles del ciclo de pruebas.

Sí, creo que se trata de entrenar a los modelos para que puedan aprender cómo escribir cualquier tipo de prueba, ¿verdad? Entonces, hay otra pregunta de J. Munro, que es, ¿esto es un producto específico? ¿Qué complemento de VSCode estarías buscando? Claro, como acabo de mencionar, Pawnee Code es una herramienta realmente buena. Tienen una CNI, tienen una extensión de VSCode. También podrías, como mencionó Valmira, probar GitHub Copilot. Aunque principalmente GitHub Copilot está destinado a sugerirte código, pero si estás escribiendo tus propias pruebas, también se puede utilizar para ayudarte a dar sugerencias para los casos de prueba, como mencionó Valmira. Por lo tanto, definitivamente puedes usar Copilot. Se integra directamente, por lo que si usas Copilot, se puede incrustar directamente en tu VSCode, y también puedes usar la extensión de VSCode para Pawnee Code. Pero también hay muchas otras herramientas que puedes usar, sí. Sí, y es posible que debas esperar en la lista de espera para Copilot, pero en algún momento llegará. Hay otra pregunta que es, según entendí, la IA crea algunos scripts. ¿Qué tan fácil es leer o verificar estos scripts por parte de los humanos? Esa es una gran pregunta. Bueno, me gustaría dividir esto en dos partes. Una es que sí, puede haber ciertos scripts que se pueden preparar, pero luego la otra parte es que simplemente puedes obtener sugerencias sobre qué casos de prueba particulares debes usar, o simplemente obtendrás bloques de código que son los propios casos de prueba. En cuanto a la parte del script, no estoy 100% seguro, porque no he trabajado realmente en ese lado yo mismo. Pero en lo que he trabajado es en la generación del código en sí. Esos se han centrado en, por ejemplo, para una función en particular, puedes corresponder directamente ese caso de prueba particular con esa función. Tiene sentido. Shibhai, fue genial tenerte aquí. Muchas gracias por tu charla. Absolutamente. Muchas gracias por tenerme, Valmir. Y muchas gracias a todo el equipo de TestJS. Gracias.