Header Ads Widget

Ticker

6/recent/ticker-posts

Prueba de contrato funcional: un estudio de caso


Los contratos, y más específicamente las pruebas de contratos , se están convirtiendo cada vez más en parte de muchas implementaciones modernas de API de WebSocket . La idea de que el intercambio de contenido puede ocurrir en forma contratada, y que estos contratos se pueden controlar y probar, es clave para muchos sistemas que utilizan configuraciones de servidor push, frontend y backend de múltiples factores.

Hoy, veremos una configuración de este tipo y veremos cómo manejan específicamente sus pruebas de contrato de WebSocket. Haremos esto mirando a Billie, una plataforma financiera cofundada por Artem Demchenkov , quien entregó la inspiración para esta pieza en la Cumbre de Plataformas 2018 de las API nórdicas . Veremos por qué su implementación es única y cómo manejan estas pruebas complejas en el entorno de producción.

Mira la sesión de Artem Demchenkov aquí:

Diapositivas

¿Qué es un contrato?

En el caso del modelo de comunicación de Billie, un contrato es esencialmente un proceso esperado o una serie de procesos entre dos componentes de microservicio. El contrato establece lo que hace cada microservicio, cómo se comunica y cuál es el formato de esas interacciones. En otras palabras, un contrato de API no es tan diferente de un contrato regular: las desviaciones de cada contrato indican un problema general en la comunicación y podrían indicar una amplia variedad de fallas.

En el caso de Billie, la naturaleza de estos contratos es aún más importante. Para comprender cómo maneja Billie sus pruebas de contrato , primero debemos comprender el modelo de comunicación subyacente que está en uso. Billie usa tres componentes básicos en su modelo: un frontend , un servidor push y un backend . Priorizan el envío de datos de usuario desde el backend al frontend, pero lo hacen sin el uso de un modelo de solicitud HTTP tradicional. ¿Como hace esto?

Podemos dividir su modelo de comunicación en cinco pasos básicos. En el primer paso, que Billie denomina Conexión WebSocket , se realiza la primera conexión del usuario al servidor push. A continuación, durante la autorización de WebSocket , los datos del usuario, específicamente el ID de usuario y la clave de API del usuario, se envían desde la interfaz al servidor push, y el usuario se autentica. Luego, estos datos se almacenan en la memoria hasta que el cliente cierra la conexión o falla la conexión. Cuando se produce un cambio en los datos internos, estos datos se envían a través del tercer paso, Cambiar , al backend. Esto luego se propaga hacia adelante mediante el cuarto paso, API Endpoint Push , que el servidor push finaliza utilizando el quinto paso, elWebSocket Push , para actualizar el cliente.

En consecuencia, la naturaleza de estos contratos determina los elementos más importantes de la comunicación, y la detección de desviaciones puede ayudar a resolver la mayoría de los problemas a medida que surgen.

El problema de las pruebas

Sin embargo, el problema con este tipo de enfoque es que existe un punto único de falla muy importante El servidor push es esencialmente el punto de control para la comunicación entre el frontend del usuario y el backend del proveedor, y con esto viene el hecho de que la falta de comunicación puede deberse a muchas cosas, desde la falta de conexión rutinaria hasta la falla catastrófica del servidor push. ¿Qué sucede si el servidor falla y no puede transferir datos? ¿Qué sucede si no puede aceptar conexiones frontend? ¿Cómo sabría el backend que ocurrió un error?

Por lo tanto, Billie se encuentra en una situación en la que el proceso debe probarse automáticamente de manera eficiente y efectiva. Se requieren pruebas automáticas adecuadas para garantizar no solo que el sistema esté funcionando, sino que los patrones de comunicación generales sean saludables y como se esperaba. Si bien Billie realiza una variedad de pruebas, el enfoque principal en el que se enfoca en esta pieza es la metodología de prueba de contrato que han denominado Prueba de contrato de pacto .

Relacionado: Utilice pruebas automáticas de documentación de API para impulsar el crecimiento de API

Prueba de contrato de pacto

En Pact Contract Testing, hay tres componentes que reflejan los tres elementos del proceso de comunicación. Estos tres componentes, el consumidor , el servidor simulado y el proveedor , reflejan el frontend, el servidor push y el backend en ese orden.

Tenemos algunas expectativas que podemos usar como base para probar las desviaciones. El consumidor espera que una determinada solicitud se derive de la red y, a cambio, espera enviar una determinada respuesta formateada. El consumidor también espera una determinada solicitud de la red y tiene su propio formato de respuesta y modelo de comunicación estrictos. El servidor push que se encuentra en el medio, conocido en este caso como servidor simulado , conoce ambos dominios y actúa como facilitador en esta prueba, gestionando todas las interacciones. La integración entre esos dos servicios se define en una unidad de datos especial escrita que Billie llama la " Interacción ", y las desviaciones de este modelo son realmente lo que se está probando.

La prueba en sí aprovecha Erlang Worldview , específicamente para su manejo de pruebas. Todo en Erlang es un proceso, y ese proceso hace lo que se supone que debe hacer o falla; esta situación de todo o nada tiene sentido en el caso de uso de Billie, ya que la interacción se preocupa principalmente por si la comunicación ocurre o no. .

El esquema de prueba del contrato refleja en gran medida el plan de comunicación regular, pero utiliza una serie de procesos de prueba en lugar del tráfico orgánico para probar cada nodo en la ruta de comunicación. Primero, el proceso de prueba genera los análogos de consumidor y servidor push en los pasos uno y dos, con el proceso de prueba funcionando esencialmente como un análogo del backend. Una vez que el proceso de prueba solicita datos de usuario del cliente, estos datos se envían al servidor push simulado para su autenticación. Desde aquí, se envía una segunda interacción desde el proceso de prueba al proceso del consumidor para reflejar el envío de datos que se produce cuando el backend se actualiza en el proceso de comunicación regular.

El proceso de prueba lo genera primero el proveedor, que inicia el servidor simulado para realizar la prueba. A continuación, se inicia el proceso de consumidor y se envía una solicitud al usuario para que proporcione sus datos de autenticación al servidor simulado. Con estos datos, el Mock Server produce la verificación, reflejando el segundo paso del proceso de comunicación regular.

Una vez que se completa esta prueba, el código se limpia solo. El proceso del consumidor finaliza, el servidor de inserción finaliza y el proceso de prueba concluye la conexión WebSocket con una falla o una aprobación .

Esta metodología de prueba se basa principalmente en la idea de procesos separados, pero también es extensible a otras soluciones. En su presentación, Artem proporciona un ejemplo de implementación de PHP : la diferencia en esta aplicación era simplemente que el consumidor ya no es un proceso, sino un objeto iniciado por el primer proceso de prueba.

Lea también: 9 tipos de pruebas para realizar en sus API

¿Qué hace posible este proceso de prueba?

Cabe señalar que existen algunos elementos del modelo Billie que permiten este tipo de pruebas. En primer lugar, este tipo de prueba es posible gracias a la relación entre cada elemento del modelo de comunicación . El backend es un proveedor de datos, el frontend es un consumidor de datos y el servidor push funciona como una unidad de comunicación.

Estas relaciones forman un patrón de comunicación muy contraído que se puede probar. Más específicamente, las interacciones entre la conexión y la autorización, así como el método fundamental de empujar desde el backend hasta el frontend, dependen por completo de un sistema de comunicación contratado que falla o tiene éxito; hay muy poca ambigüedad en dicho sistema.

El uso de Erlang Worldview también es un gran factor habilitador. Cuando todo es un proceso y cada proceso es identificable de forma única, es mucho más fácil probar estas interacciones y probar cada proceso individual.

Conclusión

Si bien, a primera vista, las pruebas de contratos parecen simples, la forma real en que Billie prueba sus relaciones es bastante interesante y muestra las dificultades para probar este tipo de relaciones.

Los contratos estrictos en sistemas que están separados entre sí hacen que las comunicaciones sean confiables, pero también hacen que las pruebas de comunicación entre ellos sean mucho más difíciles de probar; esto es doblemente cierto cuando estos procesos y servidores se eliminan entre sí y dependen de la finalización de cada uno. vía de comunicación para verificar la relación, autenticidad y validez de la vía de comunicación y los contenidos.

¿Qué opinas de este proceso? ¿Existe una forma más eficiente o eficaz de manejar este tipo de pruebas? Háganos saber a continuación.



Publicar un comentario

0 Comentarios