De Bueno a Excelente: Mejora las Pruebas con Cypress Contract Tests

Hola, bienvenidos a mi presentación de buenas a excelentes pruebas LWA con Cypress, Kotra Test. En primer lugar, es un honor para mí ser parte de TestJS Summit 2023, así que gracias por la invitación. Soy Petros Plakogiannis, tengo 15 años de experiencia en testing. Soy líder de testing e ingeniero de automation en RAS Grecia.

Solo tengo 20 minutos, así que intentaré darles tantos detalles como pueda sobre Cypress, Kotra Test. Pero primero lo primero, ¿por qué Kotra Test y qué es Kotra Test? Comencemos con un simple ejemplo de API REST. A la izquierda tenemos un cliente web que hace una llamada a la API REST para obtener algunos data. La API REST es el proveedor de data, toma data de la database y las envía de vuelta al cliente. Desde una perspectiva de testing, podemos crear pruebas de declaración de API y ejecutarlas contra un entorno de testing para verificar que el cliente obtiene los data correctos del proveedor, de la API.

¿Pero podemos aplicar esto en microservices? Los microservices son grandes proyectos de servidor que se desglosan en modules o componentes más pequeños. Diferentes equipos desarrollan y mantienen diferentes servicios, y cada servicio tiene su propia database, su propio código base, etc. El verdadero desafío es probar todos estos servicios juntos bajo un entorno de testing específico como una prueba de API tradicional. ¿Pero podemos hacer esto? Piénsalo. Diferentes equipos pueden implementar cambios en diferentes servicios al mismo tiempo, o piensa que un servicio puede estar inactivo debido a problemas de servidor, de entorno. Entonces, para probar todos estos servicios bajo un entorno específico, este entorno debe tener una configuración adecuada y datos de prueba correctos. Así que no es tan fácil.

Bueno, si solo tienes dos servicios, quizás puedas hacerlo. ¿Pero qué pasa si tienes cientos o miles de servicios como Amazon o Netflix? ¿Puedes asegurarte de que si cambias algo en un servicio, no afectarás a los demás servicios? Entonces, aquí están los desafíos.

Y por supuesto, no podemos usar pruebas unitarias. Las pruebas unitarias solo validan la lógica interna de los servicios. Piensa en cómo podemos probar un detector de humo. Si presionamos el botón de alarma, podemos escuchar el sonido de la alarma. Esta es una prueba unitaria. Pero esto solo no garantiza que el detector de humo, la alarma, se activará en presencia de humo real. Y por supuesto, no podemos incendiar la casa para verificar esto. Entonces, ¿qué podemos hacer?

Volvamos a nuestro ejemplo. Podemos usar un productor de humo para verificar que el contacto entre el detector de humo y la condición diseñada para detectar el humo se mantiene. Mientras lees la definición de pruebas de Coda de Ian Robinson, el autor del libro de prácticas de descanso y el arquitecto principal en Amazon Web Services, te informaré que las pruebas de Coda son una metodología para garantizar que dos servicios pueden comunicarse adecuadamente y captura las interacciones que se intercambian entre estos dos servicios y las almacena en el contrato. Este contrato se puede utilizar para verificar estos dos servicios. Veamos la terminología. Consumidor. El consumidor es un servicio que consume data de un proveedor. El proveedor es un servicio que proporciona data a un consumidor. El contrato del consumidor es una colección de interacciones que describen cómo el consumidor espera que se comporte el proveedor. El contrato del proveedor especifica la capacidad del proveedor. Es como un documento OpenAPI. Un intermediario de Pact es un lugar de almacenamiento. Almacenamos los contratos. Almacenamos el Pact. ¿Cómo funcionan las pruebas de contrato? Entonces, el consumidor escribe una prueba basada en lo que espera que haga el proveedor. Habla con un proveedor simulado, no con un proveedor real. Habla con un proveedor simulado creado por un Pact. Veremos más tarde cómo. Las expectativas de la prueba se registran en el contrato. Y el contrato es subido por el consumidor al intermediario de Pact. El proveedor obtiene el contrato del intermediario de Pact y hace lo que el consumidor solicitó de acuerdo con el contrato.

Pact luego verifica si el proveedor coincide con las expectativas registradas en el contrato por el consumidor. Si hay una coincidencia, entonces los dos servicios están en la misma página. Si hay una discrepancia, hay un problema y tenemos que averiguar por qué y resolverlo.

El papel de Cypress. Como puede que sepas, Cypress es un famoso marco de pruebas de extremo a extremo basado en JavaScript. Tiene muchas características, como una rica API, espera automatizada, recarga en tiempo real, depuración con viaje en el tiempo. Pero la verdadera pregunta es cómo se puede usar Cypress para escribir un contrato. Podemos convertir fácilmente un MOC de Cypress en un contrato de consumidor. ¿Cómo? Veamos un ejemplo del mundo real.

Mi empresa tiene un cliente que se llama Agencia Química Europea y hemos construido una aplicación que se llama KeZer para generar un informe de seguridad química. Para generar el informe de seguridad química, obtenemos algunos datos a través de una API de otra aplicación que se llama Euclid. Euclid tiene algunas sustancias que necesitamos obtener para generar el informe. Euclid es algo así como una base de datos. Veamos una acción. Aquí está KeZer. Voy a iniciar sesión. Aquí está Euclid. Tengo dos sustancias, Bethustodianne y Eka substance demo. Y si hago clic en Importar Sustancias Euclid a través de Webservice e ingreso la URL de Euclid y hago clic en Buscar, puedo ver las dos sustancias que puedo importar en mi aplicación. Así que tengo y también si vas a Network, puedes ver la solicitud y la respuesta, ese es el archivo JSON con dos nombres químicos. Así que he simulado esta solicitud en mi prueba de extremo a extremo. ¿Cómo? Usando el comando intercept de Cypress y aquí están mis datos simulados. Una estación de muestra. Si vas a la estación de muestra, puedes ver mis datos simulados con dos nombres químicos test.jssummit1 y test.jssummit2. Y esta solicitud se asigna a un alias para referencia futura. Así que hago mi prueba aquí y aquí, estoy esperando la decepción y luego verifico que puedo ver el test.jssummit1 en mi tabla de datos. Así que vamos a ejecutar esta prueba en Cypress. Vale, así que tengo aquí que tengo, en lugar de Petros 2.1 y Nekasubscites demo, las dos subsites que tengo, mis datos simulados, test.jssummit1 y test.jssummit2. Así que quiero convertir esta simulación en un contrato, en un pacto. ¿Cómo puedo hacer esto? Hay un plugin que se llama Pact Cypress Adapter que voy a instalar.

Bueno, entonces tienes que hacer npm install. Para instalar el plugin, ya lo he instalado en mi package.json. Aquí está el plugin, y ya he configurado el plugin en CypressConfig.js, el listener, y e2e.js, el comando de importación. Y voy a usar dos comandos, sólo dos comandos.

El primer comando es el setup-pact para configurar el nombre del consumidor y del proveedor. Así que voy a mi prueba y he usado el comando setup-pact. UIConsumer es mi consumidor, la aplicación de caso, y APIProvider es el proveedor, la aplicación EUCLID. Y luego voy a usar, en lugar del comando wait, voy a usar el comando use-pact wait. Que voy a esperar de nuevo por la intercepción, pero esta vez voy a generar el contrato. Así que vamos a ejecutar esta prueba.

Como puedes ver aquí, de nuevo tengo los datos simulados, testjs summit1 y testjs summit2, pero aquí en el archivo de prueba, he creado un contrato. Volvamos al proyecto, a la carpeta de pacto. Aquí está el contrato. Como puedes ver, es un archivo JSON que tengo el nombre del consumidor, el nombre del proveedor, una lista de interacciones que describen cómo el consumidor espera que se comporte el proveedor. Por ejemplo, necesito tener el estado 200, los nombres químicos, testjs summit1, testjs summit2, y algunos metadatos como la versión del adaptador de pacto Cypress, etc.

Ahora que he creado el contrato, tengo que compartir este archivo con un equipo de uklet que tienen un proveedor. Hay varias formas de compartir un contrato, pero por supuesto la mejor manera es tener un servidor de broker de pacto dedicado. Si tienes este servidor, puedes usar la herramienta CLI de pacto que ha sido creada por pacto, la herramienta CLI de pacto, para publicar y verificar pactos y broker de pacto directo. Veamos. Tengo un broker de pacto. Este es mi broker de pacto, motathen.packedflow.io. Aquí está la herramienta CLI de pacto. Para publicar y verificar pactos. Esa es una imagen de Docker. Puedes descargar una imagen de Docker. Tengo la imagen aquí ya en mi Docker desktop para Windows. Si sigues las instrucciones, puedes publicar el pacto. Aquí digo publicar. Doy la versión del consumidor, doy la URL base del broker, doy el token del broker que puedes encontrar si vas aquí, aquí, tokens de API. Así que voy a ejecutar este comando.

Y el pacto se publicó con éxito en el broker. Volvamos y revisemos aquí el contrato. Este es el contrato, el PACT, ¿vale? Hace unos segundos. Si haces clic en ver interacciones PACT, podemos ver esta lista de direcciones que describen cómo el consumidor espera que se comporte el proveedor. Vale, con estado 200, test json a uno, test json dos, etcétera.

Ahora, los siguientes pasos son desde el lado del proveedor, desde la utilidad, que deberían verificar el contrato. ¿Cómo pueden hacer esto? La forma más sencilla es utilizar un archivo local, lo que significa que si no tienes un broker, entonces el consumidor escribe la prueba y copian el contrato a un sistema de archivos compartido. Pero si tienes un broker PACT, como hicimos en nuestro ejemplo, no extraes el archivo PACT del sistema de archivos, sino del broker utilizando una URL.

Así que creas un webhook. Para crear un webhook, puedes utilizar la herramienta CLI de PACT o la interfaz de usuario del broker PACT. Así que si uso la herramienta CLI de PACT, puedo ir aquí y crear una prueba, una prueba de muestra, compré la biblioteca, tengo el nombre del proveedor, la URL base del proveedor, la URL del broker PACT, y uso el método verify provider. Y digo publish verification results true. Verificar un contrato es la mitad de la historia. Deberías publicar los resultados de nuevo en el broker. Puedes usar el comando docker, verificar de nuevo el conjunto, tienes que decir dar el token del broker, los resultados de la verificación pública, etcétera. Así que si ejecutas esto, va a rechazar o verificar el contrato. Vale. Pero por supuesto, puedes usar la interfaz de usuario del broker PACT. Si vas a configuración, a los webhooks, puedes crear aquí un webhook. Eso va a ser activado por tu flujo de trabajo CI-CD. Y ya que dije flujo de trabajo CI-CD, voy a mostrarte un ejemplo de flujo de trabajo CI de consumidor. Así que aquí está el inicio, el checkout, luego la instalación, ejecutas la prueba del consumidor con Cypress, publicas el contrato, el archivo packed al broker PACT, luego el flujo de trabajo CI del proveedor es activado por un webhook para verificar el pacto, el contrato, y envía de vuelta los resultados con un nuevo webhook. Y entonces, puedo usar el, puedo usar el comando de despliegue del CLI de PACT que pregunta si podemos desplegar en un entorno particular. Así que, este sería un ejemplo de, de un flujo de trabajo CI de consumidor.

Así que, resumen. Los codetests aseguran una comunicación fluida entre los microservicios reduciendo el riesgo de errores y averías. Los MOCs de Cypress pueden transformarse en contratos de consumidor de pacto utilizando el adaptador correcto y por favor usa PackBroker para gestionar tus contratos y tu flujo de trabajo CI, CD. Espero que hayas encontrado útiles los Codetests de Cypress para tu viaje de software de bueno a excelente. Gracias.