Explorando Módulos Node para Automatización de Pruebas

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.

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.

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.

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.

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.

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.