Header Ads Widget

Ticker

6/recent/ticker-posts

Generación de pruebas de API web a partir de una especificación de OpenAPI


 Esta guía explorará cómo crear pruebas para API web a partir de una especificación de OpenAPI utilizando pruebas basadas en propiedades como técnica para generar pruebas. También mostraremos un ejemplo del mundo real de cómo estas técnicas encontraron errores en el código de producción de una de las plataformas DevOps más famosas, GitLab.

OpenAPI

Las especificaciones de OpenAPI son una descripción de interfaz independiente del lenguaje de programación para las API REST. Comparable a las descripciones de interfaz en diferentes lenguajes de programación, OpenAPI le permite especificar qué necesitan los desarrolladores para integrar una API. Admite autenticación, puntos finales, verbos HTTP, parámetros, cuerpo de solicitud y datos de respuesta.

La lectura de una especificación de OpenAPI permite que tanto los humanos como las máquinas comprendan rápidamente las capacidades del servicio web subyacente.

Pruebas basadas en propiedades

Las pruebas basadas en propiedades giran en torno a generar datos de entrada y comprobar si las propiedades específicas son válidas al ejecutar las pruebas. Las pruebas basadas en propiedades ayudan a verificar que los datos de salida estén en el formato correcto y que los valores sean válidos. Hay bibliotecas disponibles para facilitar el uso de las pruebas basadas en propiedades. Estas bibliotecas suelen constar de dos partes:

  • Un generador que crea datos de prueba aleatorios que se ajustan a las necesidades de la función a probar
  • Métodos auxiliares que facilitan el uso del generador.

Las pruebas basadas en propiedades tienen que ver con fallas y son difíciles de implementar en su código, pero se pueden hacer con las bibliotecas auxiliares y las herramientas disponibles. A menudo usamos pruebas escritas con ejemplos e intentamos encontrar entradas útiles y verificar si la salida es correcta. Basado en una especificación, un enfoque de prueba basado en propiedades generará datos aleatorios como entrada y verificará si la salida es correcta.

Las pruebas basadas en ejemplos verifican lo que pensamos sobre la función a probar, mientras que las pruebas basadas en propiedades intentan demostrar que funciona como se esperaba. Por ejemplo, una prueba basada en un ejemplo podría comprobar que una función add (3, 3) = 6 funciona. Sin embargo, esa es solo una prueba, y no podemos decir con certeza que hayamos implementado la función add correctamente.

Un enfoque de prueba basado en propiedades podría probar agregar para verificar que:

  • el orden de los parámetros no importa
  • sumar (x, y) = sumar (y, x)
  • sumar 1 dos veces es igual a sumar 2
  • sumar (sumar (x, 1), 1) = sumar (x, 2)

La generación de datos y el uso de las propiedades anteriores nos daría más confianza en que la función de adición funciona como se espera en comparación con escribir algunas pruebas basadas en ejemplos.

Beneficios de las pruebas basadas en propiedades

Además de permitirnos generar miles de pruebas, la reducción de los datos de entrada es un beneficio importante de las pruebas basadas en propiedades. Al descubrir un problema, el algoritmo determinará las propiedades de los datos de entrada que afectan el resultado y generará repetidamente diferentes valores para esas propiedades. Por lo tanto, intentará descubrir el caso de prueba repetible más pequeño.

Otro beneficio es que no impondrá restricciones a los datos de entrada generados si no se indica lo contrario. Además, volver a ejecutar el mismo escenario de prueba con un valor inicial facilita la repetición de las pruebas fallidas.

Encontrar una propiedad al probar las API web

Los servicios que exponen las API web RESTful deben manejar diferentes entradas correctamente y devolver un resultado con un código de estado que una aplicación cliente pueda entender.

Hay cinco categorías de códigos de estado de respuesta HTTP, donde el primer dígito define la clase de respuesta.

  • 1XX : para obtener información, por ejemplo, el backend recibió una solicitud
  • 2XX - solicitud manejada correctamente
  • 3XX : se produjo una redirección
  • 4XX : no se puede cumplir con la solicitud del cliente, p. Ej., Sintaxis incorrecta para los datos
  • 5XX : el servidor falló internamente y no pudo satisfacer la solicitud

Por ejemplo, los puntos finales de servicio que devuelven un estado: 400 Solicitud incorrecta le dicen al cliente cortésmente que el servicio no pudo entender la solicitud y que el problema está en el lado del cliente.

La creación de una propiedad que falla en el código de estado 5XX es un buen punto de partida, ya que indica que el servicio web no pudo manejar la solicitud sin una falla interna.

Encontrar errores con herramientas existentes

Humlix es un cliente de API REST similar a Postman, pero puede generar pruebas utilizando el enfoque de prueba basado en propiedades explicado anteriormente.

Veamos un ejemplo simple de un punto final de la especificación OpenAPI de la API de GitLab Groups. Si tuviéramos que crear pruebas para este punto final, veríamos lo que espera como entrada. En este ejemplo, vemos el parámetro de consulta de página de tipo integer . Probablemente crearíamos pruebas que lo llamen usando un número negativo y un número positivo, e incluso cero.

Parece bastante simple, ¿verdad?

paths:
/v4/groups: get: tags: - groups summary: Get a groups list by page number description: Get a groups list by page number operationId: getV3Groups parameters: - name: page in: query description: Current page number schema: type: integer format: int32 responses: "200": description: Get a groups list content: application/json: schema: $ref: "#/components/schemas/Group"

¿Qué pasaría si aplicamos pruebas basadas en propiedades en el punto final y verificamos que no obtenemos ningún estado de error interno 500 en la respuesta? Podemos hacer eso con Humlix . Después de importar la especificación OpenAPI, podemos generar pruebas.

La captura de pantalla a continuación muestra que recibimos un código de estado de error interno 500 que genera pruebas. Se necesitaron pruebas de Humlix 956 para darse cuenta de que las llamadas provocaban un error dentro del backend de GitLab.<http://localhost/api/v4/groups?page=461168601842738792>

La funcionalidad de prueba basada en propiedades en Humlix generó muchos valores diferentes para el parámetro de consulta de la página . Finalmente, concluyó que 461168601842738792 es el valor más pequeño necesario para repetir la prueba fallida.

Prueba fallida de captura de pantalla de Humlix

Al ingresar al archivo production.log de GitLab , podemos ver que llamar al punto final con / api / v4 / groups? Page = 461168601842738792 causó una  excepción NumbericValueOutOfRange: Error: bigint fuera de rango en una declaración SQL.

Registro de producción de GitLab

Encontrar este problema utilizando pruebas basadas en ejemplos podría haber sido difícil. Si no pensáramos en usar un valor lo suficientemente grande, no descubriríamos este problema hasta que nuestro código se ejecute en producción.

Conclusión

Esa fue una guía rápida que muestra un pequeño ejemplo de combinación de pruebas basadas en propiedades y una especificación de OpenAPI para generar pruebas de API RESTful. Con el ejemplo del mundo real anterior, encontramos un error en el código de producción de GitLab y podemos afirmar con seguridad que lanzar software sin errores es difícil.

Estoy seguro de que GitLab tiene muchas pruebas unitarias basadas en ejemplos en su código base. Una combinación de pruebas basadas en propiedades y pruebas basadas en ejemplos les habría ayudado mucho a producir software de alta calidad.

Publicar un comentario

0 Comentarios