Explorando Módulos Node para Automatización de Pruebas

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

En mi charla exploraré los desafíos que se enfrentan al intentar gestionar y mantener el código de prueba en múltiples proyectos y qué me hizo crear mi primer módulo Javascript. Mostraré el proceso de construcción, publicación y versionado utilizando las poderosas capacidades de GitHub Actions. Y finalmente, hablaré sobre los beneficios de hacerlo.

This talk has been presented at TestJS Summit 2023, check out the latest edition of this JavaScript Conference.

FAQ

Kat Kniotek es una ingeniera de calidad que trabaja en Houseful, una empresa anteriormente conocida como Zoopla.

El propósito de crear una biblioteca propia para la automatización de pruebas es reducir la duplicación de código al utilizar ayudantes comunes y métodos de configuración que se copian de un proyecto a otro, facilitando la gestión y actualización de dependencias en múltiples proyectos.

Kat Kniotek menciona el uso de PMPM y VIT para la creación de proyectos de módulos, junto con la práctica de TDD (Desarrollo Guiado por Pruebas) en la automatización.

Kat sugiere construir el proyecto, empaquetarlo y luego publicarlo usando un flujo de trabajo de GitHub que automatiza estos pasos. También menciona la posibilidad de hacer pruebas instalando el paquete a través de un archivo local usando pmpm install y ajustando las configuraciones necesarias para autenticar el inicio de sesión en el registro de npm.

Kat incluiría ayudantes WAIT personalizados, comparadores y afirmaciones personalizadas, métodos de autenticación comunes como el cálculo de tokens Cognito, y modelos de objetos de página que se utilizan frecuentemente en diferentes proyectos.

Kat utiliza un formato de versionado mayor, menor y parche, y discute la importancia de comunicar cambios significativos mediante versiones mayores. Además, utiliza pre-lanzamientos con etiquetas como alpha o beta para gestionar versiones en desarrollo y asegurarse de que no se introduzcan errores críticos en versiones estables.

Kat opta por publicar su paquete en el feed de GitHub en lugar de npm para mantenerlo privado o restringido a su organización, configurando la visibilidad y el acceso adecuados mediante el uso de registros específicos y control de versiones.

Kat Kmiotek
Kat Kmiotek
19 min
11 Dec, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Esta charla explora el proceso de construcción de una biblioteca de automatización de pruebas utilizando módulos node, con un enfoque en la creación de la estructura del proyecto, la construcción y prueba de la biblioteca, y la publicación y versionado del paquete. Se discute la inclusión de características útiles como los ayudantes WAIT y el uso de bibliotecas como Playwright y Cypress. Se enfatiza la importancia de una documentación clara, versiones previas a la publicación y control de versiones, junto con la necesidad de instrucciones de instalación y pautas de contribución.

1. Introducción a la Construcción de la Biblioteca de Automatización de Pruebas

Short description:

Hablaré sobre la exploración de módulos de nodo para la automatización de pruebas. Te guiaré a través del proceso de construir tu propia biblioteca, publicarla en npm y luego usarla. Hoy, hablaré sobre la creación de un proyecto de módulo con PMPM y VIT. Hablaré sobre el desarrollo guiado por pruebas, probándolo. Hablaré sobre la selección de registros NPM, es decir, dónde publicarás tu paquete. Te mostraré un ejemplo del flujo de trabajo de la tubería de GitHub utilizado para publicar una nueva versión, pero también prelanzamientos. Hablaré sobre lo importante que es la versión del proyecto y la importancia de agregar un Readme. Pero antes de comenzar a sumergirnos en cómo construir tu propia biblioteca, me gustaría hacer la pregunta, y tal vez discutir primero, ¿qué incluiría esta biblioteca? ¿Qué tipo de ayudantes? A menudo te encuentras copiando y pegando de proyecto a proyecto, así que ¿qué ayudantes serían buenos para estar en esta biblioteca de pruebas? A menudo me encuentro usando ayudantes WAIT. No importa si trabajas con Playwright, Cypress, Selenium.

Hola a todos, mi nombre es Kat Kniotek. Trabajo como ingeniera de calidad en Houseful, anteriormente conocida como Zoopla. Gracias por unirte a mi charla hoy.

Hablaré sobre la exploración de los modules de nodo para la automation de pruebas. Te guiaré a través del proceso de construir tu propia biblioteca, publicarla en npm, y luego usarla.

Entonces, podríamos comenzar con la pregunta, ¿por qué? ¿Por qué crearías tu propia biblioteca para la automation de pruebas? Así que, estaba trabajando con dos enfoques para las pruebas. El primero, el marco de pruebas viviría en un repositorio separado. Sería un lugar único para administrar las dependencias de las pruebas. Las pruebas compartirían ayudantes y métodos de configuración. Las pruebas serían mantenidas por el equipo de QA. Podrías tener frameworks separados para las pruebas de UI y para las pruebas de API, pero principalmente el equipo de QA sería responsable de actualizarlo, agregarlo, depurar pruebas inestables. El segundo enfoque con el que trabajé, y siendo honesta, es que las pruebas viven con el proyecto, con el proyecto de la aplicación. Y luego pueden ser mantenidas por los desarrolladores. Entonces, digamos que configuraría este marco y los desarrolladores estarían agregando pruebas, actualizando pruebas según sea necesario. Sin embargo, este enfoque introdujo mucha duplicación de código. Cada vez que estamos creando una nueva API, un nuevo servicio, me encontraba copiando, pegando de un proyecto a otro ayudantes, la configuración de configuración para el proyecto. Y también cuando tenía que actualizar una de las dependencias, dependencias de prueba, tenía que actualizar en cinco lugares. Realmente no era el camino a seguir. Por eso decidí investigar la construcción de mi propia biblioteca que incluiría todos los ayudantes que copio y pego de repositorio a repositorio. Podría simplemente instalar esta biblioteca en un proyecto y luego usar ayudantes según sea necesario.

Entonces hoy, hablaré sobre la creación de un proyecto de módulo con PMPM y VIT. Hablaré sobre el desarrollo guiado por pruebas, testing. Como ingenieros de automation, no a menudo tenemos la oportunidad de practicar TDD. Esta es la oportunidad. Hablaré sobre la selección de registros NPM, es decir, dónde publicarás tu paquete. Te mostraré un ejemplo del flujo de trabajo de la tubería de GitHub utilizado para publicar una nueva versión, pero también prelanzamientos. Hablaré sobre lo importante que es la versión del proyecto y la importancia de agregar un Readme. Esos son algunos puntos que trataré. Pero antes de comenzar a sumergirnos en cómo construir tu propia biblioteca, me gustaría hacer la pregunta, y tal vez discutir primero, ¿qué incluiría esta biblioteca? ¿Qué tipo de ayudantes? A menudo te encuentras copiando y pegando de proyecto a proyecto, así que ¿qué ayudantes serían buenos para estar en esta biblioteca de pruebas? A menudo me encuentro usando ayudantes WAIT. No importa si trabajas con Playwright, Cypress, Selenium.

2. Creación de la Biblioteca de Pruebas y Estructura del Proyecto

Short description:

Podemos almacenar nuestros ayudantes WAIT personalizados, comparadores, afirmaciones y configuración en la biblioteca de pruebas. Los métodos de autenticación, los modelos de objetos de página y los ayudantes del cliente API también pueden incluirse. Para crear la biblioteca, podemos usar la herramienta de línea de comandos para pnpm y responder algunas preguntas sobre el marco, seleccionando el tiempo de ejecución como biblioteca y el lenguaje como TypeScript para la seguridad de tipo.

Todos tenemos nuestros ayudantes WAIT personalizados que probablemente sean particulares para la aplicación en la que trabajamos, y pueden almacenarse en nuestra nueva biblioteca de pruebas. Tal vez creaste tus propios comparadores y afirmaciones personalizadas, y realmente te gusta la forma en que funcionan, y quieres usarlos en otros proyectos. Así que, en lugar de copiar y pegar, puedes colocarlos en esta biblioteca de pruebas.

La configuración de tu prueba, también puede ser compartida. Los métodos de Authentication, así que digamos que trabajas con, pruebas de API, y la authentication para el servicio es CognitoToken, y cada una de las APIs, cada uno de los proyectos usa el mismo método de authentication. Así que tienes este ayudante para calcular el token base64 a partir de las credenciales. Esto también puede ir a la biblioteca de ayudantes. Modelos de objetos de página, tal vez cada una de tus pruebas interactúa con la página de inicio de sesión, y la página de inicio de sesión es la misma para todas las aplicaciones. Tal vez este modelo de objeto de página de inicio de sesión podría vivir en la biblioteca. Y los ayudantes del cliente API y la configuración, configurando encabezados personalizados y así sucesivamente.

Así que cuando estamos empezando la línea de comandos, en lugar de hacer toda la configuración del proyecto y demás, podemos usar la herramienta de línea de comandos para pnpm y crear el proyecto bit. Se te pedirá que respondas algunas preguntas sobre el marco. No estamos usando ninguna vista React o algo así. Simplemente estamos usando otro. El Runtime a seleccionar será biblioteca. Eso es realmente útil porque eso es lo que estamos construyendo. El lenguaje, seleccioné TypeScript para hacer nuestra biblioteca segura en términos de tipos. Si alguna vez has usado ese tipo de herramienta de línea de comandos, como NPX, crear aplicación React o similar, sabes que eso es lo que construirá para ti como la estructura del proyecto con mucho código predefinido.

3. Construcción y Pruebas de la Biblioteca

Short description:

En nuestro ejemplo, podemos eliminar todo lo que esté relacionado con HTML. No vamos a ejecutar nuestra aplicación en el navegador. Por lo tanto, HTML, CSS, SVG, no serán útiles en nuestro proyecto. Puedes empezar a instalar tus bibliotecas favoritas como Playwright, Cypress, FakerJS. Todos tus ayudantes deben ir al directorio lib en el archivo TS principal. Una vez que tengas definidos todos tus ayudantes, puedes exportarlos en un archivo index.d.ts.

Código. En nuestro ejemplo, podemos eliminar todo lo que esté relacionado con HTML. No vamos a ejecutar nuestra aplicación en el navegador. Así que HTML, CSS, SVG, no serán útiles en nuestro proyecto. Luego puedes empezar a instalar tus bibliotecas favoritas. Digamos Playwright, digamos Cypress, FakerJS o similares. Y todos tus ayudantes deben ir al directorio lib, al archivo TS principal. Y aquí hay un ejemplo de cómo se ve mi archivo TS principal. Tiene algunos métodos, algunas funciones. La primera es la que mencioné, me gusta usar un ayudante de espera personalizado. Esto es para Playwright. Espero una respuesta particular en la pestaña de red, y luego continúo con mis pruebas. La que también mencioné, calculando el token de Cognito a partir de las variables de entorno y devolviendo la cadena, y el ayudante de demostración para simplemente imprimir hola, nombre. Así que algo bastante fácil, fácil de probar. Y luego, una vez que tengas definidos todos tus ayudantes, bueno, puedes empezar con uno o unos pocos. Necesitas exportarlos en un archivo index.d.ts Este archivo está por defecto en la raíz de tu proyecto. Así que aquí exportas esas funciones que estarán disponibles desde la biblioteca.

Bueno, ¿y luego qué? Testing. Puedes instalar vtest. Digamos que puedes añadir tus pruebas unitarias para tus métodos, y por supuesto asegúrate de que la etapa de prueba está incluida en el pipeline en el flujo de trabajo. Pero, ¿cómo probamos realmente nuestra solución? Así que, construimos el proyecto, y, en teoría, todo está bien porque simplemente copiamos el código, trabajamos en otro lugar, ¿cómo lo probamos?, podemos instalarlo y acceder a esos métodos que son públicamente accesibles una vez que el paquete está construido. Así que, construiremos el proyecto, y luego lo empaquetaremos. Algo que sucederá en el pipeline, en el pipeline construiremos, y luego publicaremos. Publicar por defecto empaqueta nuestro proyecto. Y como resultado del comando PMPM pack, se creará un archivo, que es básicamente el nombre del proyecto de package.json con el número de versión. Y esta es nuestra biblioteca. ¿Cómo podemos probarla? Podemos crear un proyecto separado y simplemente instalarlo. Algo que aprendí como parte del trabajo en este proyecto es que puedes instalar la biblioteca desde el archivo. Así que si ejecutas pmpm install path to your file, como puedes ver en el ejemplo, eso se instalará en tu package.json. Es fantástico.

4. Pruebas y Publicación del Paquete

Short description:

Puedes probar tu paquete importándolo y actualizando los métodos si es necesario. Para hacer que tu paquete esté disponible, puedes almacenarlo en npm o usar el feed de GitHub. El flujo de trabajo de GitHub se puede utilizar para publicar el paquete, incluyendo versiones pre-lanzamiento. El flujo de trabajo se activa en las solicitudes de extracción y autentica tu inicio de sesión en el registro de npm.

Y luego puedes simplemente probarlo como importar print hello desde mis ayudantes de prueba, y funciona. Bueno, no funcionó la primera vez. Así que no te desanimes si no funciona la primera vez. Puedes simplemente actualizar los métodos. Quizás olvidaste exportarlo en el archivo index, reconstruirlo y publicarlo de nuevo, empaquetarlo de nuevo. Obviamente es un ensayo y error y es un gran aprendizaje.

Así que una vez que tenemos nuestro proyecto construido, sabemos que funciona porque podemos instalarlo en otro proyecto. Necesitamos empezar a pensar cómo lo haremos disponible en repositorios y en otros equipos. Una de las soluciones para publicar nuestro paquete sería almacenarlo en npm. Puedes registrarte en npm y publicar tu paquete allí. Si estás utilizando una cuenta gratuita, tienes permiso para publicar paquetes públicos. Sin embargo, si sientes que tu proyecto, tu módulo contiene algo relacionado con la aplicación, no quieres exponer esto al mundo exterior o algo así, simplemente no quieres hacerlo público, necesitarías una cuenta de pago o enterprise. Como no lo tengo, decidí publicar mi paquete con el feed de GitHub. También es un registro de npm. Simplemente especificas una URL de registro diferente que apunta a tu registro de GitHub. También puedes crear el paquete a nivel de organización. Puedes hacerlo privado, público. Aquí solo hay un ejemplo. Estaba usando mi propia cuenta de GitHub.

Así que podríamos usar todos los comandos como build, pack, publish localmente. Podríamos iniciar sesión en el registro localmente y publicarlo desde allí. Sin embargo, desde el punto de vista del mantenimiento, queríamos que estuviera controlado por el control de fuente, por el control de versión. Así que aquí está el ejemplo de un flujo de trabajo de GitHub que estará publicando nuestro paquete. Estará publicando el paquete pre-lanzamiento. Hablaré de ello más tarde. Pero lo que puedes ver aquí es un disparador. Así que este flujo de trabajo se activará cada vez que se cree una solicitud de extracción contra la rama principal. Esto comprobará nuestro código y creará un archivo .npmrc. Este archivo se utiliza para autenticar tu inicio de sesión en el registro de npm. Porque como puedes ver en la segunda línea, 19, incluye el secreto.

5. Publicación y Versionado del Paquete

Short description:

No quería comprometerlo con el repositorio. Por eso escribo en el archivo como un paso de la tubería y tengo acceso a mi secreto aquí. Cuando ejecutas la tubería, la salida se ve más o menos así. Está en la línea 12, tienes tu archivo index.d.ts, así que el archivo que exporta realmente métodos y funciones que se utilizan. Pero también en la línea 17, tienes exactamente el nombre del archivo que estábamos probando localmente cuando estábamos ejecutando el método pnpm pack. Si obtienes 405, asegúrate de que tu paquete esté nombrado correctamente. Una vez que lo publicas, tu paquete está disponible en GitHub. Tienes información sobre cómo instalarlo, cómo añadirlo a packet.json, tienes información sobre las versiones anteriores. En el lado derecho, también tienes el readme, y el enlace al repositorio. Hablemos ahora del versionado. El estándar para el versionado es el formato mayor, menor, parche. Eso se traduce en, digamos, mayor uno, menor tres y parche es cero. Así que, cuando vayas a lanzar un cambio importante, querrás comunicar al usuario que puede que necesite actualizar el uso de tu biblioteca, y lo haces lanzando versiones mayores. Y esto es comúnmente conocido como el problema del huevo y la gallina.

No quería comprometerlo con el repositorio. Por eso escribo en el archivo como un paso de la tubería y tengo acceso a mi secreto aquí. Ahí están los secretos del repositorio. Así que creo este archivo npmrc. Instalo las dependencias, ejecuto mis pruebas y construyo el proyecto, y luego puedo publicar, como dije, en mi registro de GitHub que incluye también mi nombre de usuario.

Cuando ejecutas la tubería, la salida se ve más o menos así. Está en la línea 12, tienes tu archivo index.d.ts, así que el archivo que realmente exporta métodos y funciones que se utilizan. Pero también en la línea 17, tienes exactamente el nombre del archivo que estábamos probando localmente cuando estábamos ejecutando el método pnpm pack. De nuevo, igual que antes, no funcionó la primera vez. No funcionó la segunda vez. Cuando intentaba publicar en mi feed de GitHub, a menudo, obtenía 404 o 405. Y descubrí la forma de autenticarlo, así que como decía, el archivo .npmrc necesita incluir el secreto y la URL correcta del registro. Sin embargo, el nombre de tu paquete también necesita incluir tu nombre de usuario de GitHub. Eso fue un aprendizaje interesante. Si obtienes 405, asegúrate de que tu paquete esté nombrado correctamente.

OK. Así que, una vez que lo publicas, tu paquete está disponible en GitHub. Tienes información sobre cómo instalarlo, cómo añadirlo a packet.json, tienes información sobre las versiones anteriores. En el lado derecho, también tienes el readme, y el enlace al repositorio. Es realmente agradable, ¿no es así? Así que, como puedes ver aquí, hay diferentes versiones, la versión reciente, hay alfa y así sucesivamente. Hablemos ahora del versionado. Así que, el estándar para el versionado es el formato mayor, menor, parche. Eso se traduce en, digamos, mayor uno, menor tres y parche es cero. Así que, cuando vayas a lanzar un cambio importante, querrás comunicar al usuario que puede que necesite actualizar el uso de tu biblioteca, y lo haces lanzando versiones mayores. Así que, digamos que aumentas el número mayor a dos, tendrás la versión 2.0.0. Si lanzas este pequeño cambio en tu aplicación, quizás solo añades una función de ayuda adicional, simplemente aumentarías la versión menor. Así que, 1.4.0. Y cuando trabajas con parches, así, como las pequeñas correcciones, quizás actualizaste el readme o algo así, simplemente actualizarías la versión del parche. Sin embargo, cuando trabajas con el paquete, y creas el PR, actualizas el código, y lanzas este paquete, probablemente crearías solo una actualización de parche 1.3.1.

6. Publicación de Pre-lanzamientos y Control de Versiones

Short description:

Al trabajar con pull releases, es común agregar versiones de pre-lanzamiento como alpha, beta o RC para evitar la publicación de cambios que rompen. A pesar de esto, sigue siendo importante publicar pre-lanzamientos para fines de prueba. Hay varias herramientas disponibles para ayudar a controlar el versionado, como package.json, Git version, GitHub actions y tags. Se recomienda elegir uno y consultar la documentación para obtener orientación. Además, es crucial proporcionar instrucciones de instalación claras, pautas de contribución y ejemplos para los usuarios, que pueden ser ingenieros de calidad o desarrolladores.

Y esto se conoce comúnmente como el problema del huevo y la gallina. Porque tu PR podría ser, tu pull request podría estar creando el cambio que rompe para el usuario, o tu código de pull request podría no estar completo, podría no estar funcionando como el usuario esperaría. Pero si tienen en su package.json, versión anclada de esta manera, en lugar de que mis ayudantes de prueba estén anclados a la versión 1.3.1, permiten que se instalen todas las versiones por encima de esta versión. Entonces, si estás introduciendo el cambio que rompe, consumirían este código como parte de la instalación de dependencias. Por eso, cuando trabajamos con pull releases, a menudo usamos, agregaremos, digamos, guión alpha, guión beta, o RC release candidate, para asegurarnos de que no estamos publicando un lanzamiento real, como el lanzamiento completo. Y lo marcamos con cualquier conversión que se use en el proyecto.

Entonces, puedes preguntar, vale, ¿por qué incluso lo publicamos si eso podría ser un cambio que rompe? Tal vez no deberíamos publicarlo aún si todavía trabajamos en pull request, si no se ha fusionado. Pero al mismo tiempo, quieres poder probarlo. Quieres publicar este pre-lanzamiento alpha, y luego quieres instalarlo en otro proyecto. Y puedes usarlo simplemente agregando alpha punto cero y npm install.

Otro aprendizaje como parte de este proyecto fue descubrir que hay muchas herramientas que pueden ayudarte a controlar el versionado de tu proyecto. Esto se puede hacer a través de package.json. Hay un atributo de versión. Esto se puede hacer con Git version, en realidad una herramienta. Esto se puede hacer con GitHub actions o tal vez con las tags de GitHub. Hay muchas formas de hacerlo. Lo que recomendaría es elegir uno de ellos y entrar en la documentation y averiguar cómo usarlo. Me confundí un poco en el camino cuando estaba trabajando en ello. Así que sí, revisa la documentation de la herramienta que decidas usar. Y léeme. Entonces, ¿quién es tu usuario? Tu usuario es otro ingeniero de calidad y tu usuario es un desarrollador. Necesitan saber cómo instalar tu proyecto, cómo contribuir a él y cómo usarlo. Así que ambos ayudantes están disponibles para ellos. Así que un ejemplo, cómo el proceso de instalación y la guía de contribución. Y eso es todo. Espero que hayas disfrutado de esta masterclass, que hayas aprendido algo nuevo. Tal vez decidas llevar este aprendizaje y construir algo para tu equipo también. Y espero que disfrutes de otras masterclass en Test.js. Gracias.

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

Solicitudes de Red con Cypress
TestJS Summit 2021TestJS Summit 2021
33 min
Solicitudes de Red con Cypress
Top Content
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.
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Node Congress 2022Node Congress 2022
26 min
Es una jungla ahí fuera: ¿Qué está pasando realmente dentro de tu carpeta Node_Modules?
Top Content
The talk discusses the importance of supply chain security in the open source ecosystem, highlighting the risks of relying on open source code without proper code review. It explores the trend of supply chain attacks and the need for a new approach to detect and block malicious dependencies. The talk also introduces Socket, a tool that assesses the security of packages and provides automation and analysis to protect against malware and supply chain attacks. It emphasizes the need to prioritize security in software development and offers insights into potential solutions such as realms and Deno's command line flags.
Pruebas de ciclo completo con Cypress
TestJS Summit 2022TestJS Summit 2022
27 min
Pruebas de ciclo completo con Cypress
Top Content
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.
Automatizando Todo el Código y las Pruebas con GitHub Actions
React Advanced 2021React Advanced 2021
19 min
Automatizando Todo el Código y las Pruebas con GitHub Actions
Top Content
We will learn how to automate code and testing with GitHub Actions, including linting, formatting, testing, and deployments. Automating deployments with scripts and Git hooks can help avoid mistakes. Popular CI-CD frameworks like Jenkins offer powerful orchestration but can be challenging to work with. GitHub Actions are flexible and approachable, allowing for environment setup, testing, deployment, and custom actions. A custom AppleTools Eyes GitHub action simplifies visual testing. Other examples include automating content reminders for sharing old content and tutorials.
Desarrollo Efectivo de Pruebas
TestJS Summit 2021TestJS Summit 2021
31 min
Desarrollo Efectivo de Pruebas
Top Content
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.

Workshops on related topic

Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
React Summit 2023React Summit 2023
151 min
Diseñando Pruebas Efectivas con la Biblioteca de Pruebas de React
Top Content
Featured Workshop
Josh Justice
Josh Justice
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
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
React Summit 2022React Summit 2022
117 min
Detox 101: Cómo escribir pruebas de extremo a extremo estables para su aplicación React Native
Top Content
Workshop
Yevheniia Hlovatska
Yevheniia Hlovatska
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
Masterclass de Pruebas de API con Postman
TestJS Summit 2023TestJS Summit 2023
48 min
Masterclass de Pruebas de API con Postman
Top Content
WorkshopFree
Pooja Mistry
Pooja Mistry
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.
Monitoreo 101 para Desarrolladores de React
React Summit US 2023React Summit US 2023
107 min
Monitoreo 101 para Desarrolladores de React
Top Content
WorkshopFree
Lazar Nikolov
Sarah Guthals
2 authors
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
Masterclass de Node.js
Node Congress 2023Node Congress 2023
109 min
Masterclass de Node.js
Top Content
Workshop
Matteo Collina
Matteo Collina
¿Alguna vez has tenido dificultades para diseñar y estructurar tus aplicaciones Node.js? Construir aplicaciones que estén bien organizadas, sean probables y extensibles no siempre es fácil. A menudo puede resultar ser mucho más complicado de lo que esperas. En este evento en vivo, Matteo te mostrará cómo construye aplicaciones Node.js desde cero. Aprenderás cómo aborda el diseño de aplicaciones y las filosofías que aplica para crear aplicaciones modulares, mantenibles y efectivas.

Nivel: intermedio
Testing Web Applications Using Cypress
TestJS Summit - January, 2021TestJS Summit - January, 2021
173 min
Testing Web Applications Using Cypress
Top Content
Workshop
Gleb Bahmutov
Gleb Bahmutov
Esta masterclass te enseñará los conceptos básicos para escribir pruebas end-to-end útiles utilizando Cypress Test Runner.
Cubriremos la escritura de pruebas, cubriendo cada característica de la aplicación, estructurando pruebas, interceptando solicitudes de red y configurando los datos del backend.
Cualquiera que conozca el lenguaje de programación JavaScript y tenga NPM instalado podrá seguir adelante.