Header Ads Widget

Ticker

6/recent/ticker-posts

Uso del desarrollo basado en pruebas para microservicios


 El paradigma de diseño de microservicios se ha convertido en una metodología de diseño de software prominente ahora que las industrias de API primero adoptan un estrato operativo más desacoplado. En el pasado, hemos hablado de la coreografía asincrónica , el diseño de BFF y el control de identidad para microservicios. Sin embargo, queda una pregunta: ¿cuál es el medio más eficaz para probar microservicios?

El desarrollo basado en pruebas o TDD es una filosofía de desarrollo que enfatiza ciclos de desarrollo muy cortos. Con TDD, los equipos de desarrollo trazan sus requisitos comerciales y describen casos de uso de comportamiento específicos para verificar. TDD para API se ha convertido en una práctica común, sin embargo, ¿cómo realizamos TDD eficiente con recursos limitados en todo un ecosistema de microservicios?

En este artículo, demostraremos un caso de estudio para establecer una metodología de prueba reutilizable para una plataforma de microservicio . Guiados por el conferencista de Platform Summit Michael Kuehne-Schlinkert de Cybus , identificaremos tipos de pruebas (como pruebas de plataforma, pruebas de integración, pruebas funcionales y pruebas unitarias). Luego, nos centraremos en la estrategia de prueba de Cybus como un caso de estudio para probar un ecosistema de microservicios, rastreando su ciclo desde pruebas holísticas de caja negra hasta pruebas precisas de unidades de caja blanca.

Esta es una publicación complementaria a la presentación de Michael Kuehne-Schlinkert en las API nórdicas:

Ver diapositivas de presentación aquí

Desarrollo basado en pruebas para API y microservicios

El uso de TDD para el desarrollo web, específicamente con microservicios y API, significa pruebas iterativas de comportamientos específicos. Esto podría implicar pruebas iterativas de llamadas a API en un proyecto separado para pruebas de API, reparación de fallas y codificación de nuevas funcionalidades en un sistema. El software se desarrolla o mejora para pasar estos casos de uso, y este proceso se repite para introducir comportamientos sucesivos.
El proceso TDD de Steve Klabnik para API busca validar que la API esté funcionando según lo previsto . En 2012 describió TDD para API con los siguientes pasos:

1. Escriba una prueba para algún comportamiento que le gustaría introducir en su sistema.
2. Ejecute su conjunto de pruebas y asegúrese de que la prueba falle.
3. Escriba el código más simple que implemente el comportamiento.
4. Ejecute su conjunto de pruebas y asegúrese de que la prueba pase.
5. Refactorice, porque el código más simple a menudo tiene propiedades indeseables.
6. Comprometerse y GOTO 1.

El concepto de desarrollo impulsado por pruebas ha sido popular desde principios de la década de 2000, y gran parte del proceso de Klabnik todavía se aplica. Sin embargo, con el auge de los microservicios, algunos desarrolladores están ampliando los métodos de prueba tradicionales para responder nuevas preguntas: ¿Cómo validamos que un sistema de microservicios se está comportando como se esperaba? Y lo que es más importante, ¿cómo creamos pruebas eficientes y repetibles ?

Michael cree que el objetivo contemporáneo es descubrir cómo validamos de manera eficiente que nuestro ecosistema de microservicios funciona según lo previsto . En lugar de dividirnos en una sola API, ahora debemos imaginar que todo el ecosistema funcione en sincronía.

Cybus: estudio de caso

La startup de Michael, Cybus , trabaja con protocolos industriales para actuar como una capa segura entre los dispositivos fuera de línea y los servicios en línea, y como probablemente habrá adivinado, su plataforma funciona con una arquitectura de microservicios.

Naturalmente, los proveedores de datos como servicio como Cybus deben realizar pruebas rigurosas para cumplir con sus acuerdos de nivel de servicio. Sin embargo, según Michael, el verdadero motor para crear una estrategia de prueba repetible fue tener una respuesta ágil a las necesidades de sus clientes . No está de más mencionar que la estrategia TDD de Cybus debe ser eficiente y ágil, ya que es una startup que trabaja con un equipo de desarrollo de tres personas.

Paso uno: crear una historia para el ecosistema

Entonces, para un ecosistema de microservicios, ¿por dónde empezar a realizar pruebas? Michael cree que un lugar útil para comenzar es crear primero una historia . Establece una rúbrica simple para describir una historia:

As a 
I want 
So that 

Por ejemplo, supongamos que desea controlar la capacidad de acceso de lectura a los dispositivos para que los usuarios solo puedan leer los datos que pueden leer, una técnica común de asignación de permisos con niveles de aprovisionamiento o niveles de acceso a datos. La plantilla anterior podría completarse para describir un administrador del sistema (función) que quiere controlar el acceso de lectura a mis dispositivos (función) para que los usuarios solo puedan ver los datos que se supone que deben ver (razón).

La elaboración de una historia te coloca en el asiento del usuario para comprender sus motivaciones, y la creación de estas historias es fundamental para crear escenarios técnicos para luego probar.

Paso dos: crear el escenario

A continuación, podemos usar la historia para generar el escenario , que es más un flujo de trabajo técnico detrás de la motivación del usuario. Hay varios tipos de escenarios para diferentes casos de uso, pero un buen lugar para comenzar es un escenario por servicio. El equipo de Cybus estructura sus escenarios en una forma de expresión similar a IFTTT similar a Gherkin , el lenguaje para el desarrollo impulsado por el comportamiento:

GIVEN 
WHEN 
THEN 

Para una situación en la que el administrador desea controlar el acceso a los dispositivos, este escenario podría involucrar tres servicios en servidores no aislados que deben comunicarse entre sí: un servicio de interfaz de usuario que proporciona información a los usuarios finales, un servicio de dispositivo que es legible por máquina y un servicio OAuth para autorización.

El escenario podría describirse de la siguiente manera:

GIVEN External Device
GIVEN Device Service
GIVEN OAuth Service
WHEN External Device provides new data
WHEN Read Access to Device is granted
THEN Device Service reads data from external service.

Como una receta para una sola historia, trazamos los supuestos dados y explicamos lógicamente el evento y el resultado esperado. Para los casos en los que hay un dispositivo o servidor externo que se comunica con el ecosistema, es difícil validar su comportamiento ya que no se tiene control sobre él. Entonces, el equipo de Cybus detecta cosas externas que no pueden controlar.

Relacionado: 6 consejos para convertirse en un jardinero experto en microservicios

Convierta los escenarios en pruebas de aceptación

Con estos, el equipo de Cybus realiza pruebas de aceptación , en las que realizan pruebas de caja negra: observan todo el arreglo antes de sumergirse en los detalles esenciales.

Prueba de plataforma

Primero, realizan pruebas de caja negra de toda la plataforma para verificar que la funcionalidad funcione en todo el ecosistema; prueban todos los microservicios involucrados en estos escenarios de gran alcance, detectando dispositivos externos en el proceso.

Además de probar la API, el equipo también prueba la interfaz gráfica de usuario (GUI), simulando comportamientos del usuario como hacer clic para crear llamadas simuladas. Simular la experiencia del usuario final es fundamental para que el equipo se asegure de que la API impulse experiencias de calidad para los clientes.

Pruebas de contrato

Las pruebas de contrato también forman parte del proceso de prueba de aceptación. Aquí es cuando el equipo prueba la interfaz de microservicios para validar sus esquemas JSON. Lo que buscan aquí es si la interfaz del servicio se desvía o no del contrato . Esto ayuda a validar el desarrollo basado en pruebas y ayuda a evitar los hábitos de codificar primero.

Luego vienen las pruebas de integración

Hasta ahora, nuestras pruebas se han centrado en la sincronicidad de la plataforma, pero como podría pensar, un alcance puramente grande no es suficiente. Lo que realmente necesitamos es un enfoque más detallado con pruebas de integración , también conocidas como pruebas de componentes .

Las pruebas de integración toman un escenario específico y lo convierten en una prueba para un servicio específico. Volviendo a nuestro escenario de control de acceso a dispositivos, las pruebas de integración implicarían un solo caso de prueba por servicio dentro de cada historia, como una prueba aislada del servidor OAuth.

Aunque las pruebas de microservicios se realizan como una caja negra, resguardan y simulan pruebas externas. Dado que el estilo Cybus de pruebas de integración es específico del servicio , pero no completamente de un extremo a otro, lo llaman prueba de caja gris .

Pruebas funcionales

Luego viene un enfoque aún más profundo. Para el equipo de Cybus, las pruebas funcionales dentro de Node.js significan probar las comunicaciones entre módulos específicos Deben asegurarse de que dos componentes individuales se comporten e interactúen entre sí de la manera correcta. Las pruebas funcionales implican pruebas de caja blanca para clases específicas y burlarse de todas las demás comunicaciones en torno a los servicios.

Michael hace referencia a un ejemplo sería probar la comunicación entre dos componentes, como el controlador y el controlador de dispositivos dentro de un microservicio. Este es un gran comienzo, pero las pruebas completas requieren un enfoque aún más profundo.

Pruebas unitarias

La prueba unitaria es la caja blanca definitiva. Todos los mecanismos circundantes se dejan de lado y las pruebas se centran en una sola unidad, como una clase o módulo dentro de un dominio específico. Las pruebas unitarias son críticas, esenciales para las operaciones; Las API y los microservicios simplemente no pueden vivir sin él.

Sobre la sincronicidad de microservicios: API asincrónicas en microservicios coreografiados

El ciclo TDD

Ahora que hemos definido los tipos de prueba individuales, ¿cómo atraviesa realmente un equipo el ciclo impulsado por pruebas? Para Cybus, es algo como esto:

Reutilizado de la diapositiva 13 " Nuestro ciclo TDD "

La prueba comienza con la aceptación de la caja negra, pasa a la integración de la caja gris y luego a la prueba de la unidad de la caja blanca. Después de eso, codifican, realizan más pruebas unitarias, reiteran algunas más y realizan pruebas de integración. Curiosamente, el equipo de Cybus escribe sus pruebas funcionales en el camino de regreso en el ciclo.

Michael señala que intentar probar todos los casos de uso y escenarios significa una cantidad asombrosa de casos de prueba, pero el objetivo es tener una cobertura de prueba unitaria cercana al 100%. Tras dominar este ciclo, el equipo ha creado código reutilizable para realizar pruebas, así como muchas bibliotecas de prueba para volver a implementar. Michael todavía anima a los desarrolladores a conocer su entorno y lo que funciona para ellos.

Pensamientos finales: requisitos comerciales Direct TDD

Lo interesante es que adoptar una mentalidad TDD significa que las empresas necesitan un desarrollo directo . Privilegiar la historia del cliente significa que las funciones se adaptan a los deseos de la base de usuarios y, por lo tanto, se mantienen los objetivos comerciales. Para Cybus, esta primera evaluación de caso de uso para probar su plataforma de microservicios también da como resultado una cobertura de prueba de alto porcentaje, una reutilización de prueba mejorada y una biblioteca de códigos de prueba expansiva.

Algunos pensamientos duraderos sobre el desarrollo impulsado por el comportamiento:

  • Conozca su entorno y lo que funciona para usted : dado que la terminología y los procesos establecidos en esta publicación se derivan del equipo de Cybus, es posible que no se apliquen a todas las situaciones.
  • Reutilización : el desarrollo de código reutilizable para pruebas hará que las pruebas sean eficientes, especialmente para equipos pequeños.
  • El trabajo intensivo vale la pena : la creación de bibliotecas de prueba es un comienzo difícil, pero al final vale la pena.
  • Dependencias : cree bibliotecas de prueba individuales para cada servicio y conviértalo en un punto de referencia para introducir nuevas dependencias.

Teniendo en cuenta que estamos intentando crear API que duren décadas , Michael también señala que:

"Una clave sólida para asegurarnos de que creamos API duraderas es utilizar el desarrollo basado en pruebas"

Recursos útiles sobre TDD

  • TDD Su API : Steve Klabnik de Balanced Payments documenta su proceso de prueba / desarrollo de API.
  • Introducción al desarrollo basado en pruebas

Publicar un comentario

0 Comentarios