servicios - Pruebas automáticas para REST Api

rest assured examples

Question

Me gustaría escribir un conjunto de pruebas automatizadas para una API REST. A medida que completemos nuevos servicios, nos gustaría verificar que todos los servicios creados anteriormente funcionen como se esperaba. ¿Alguna sugerencia sobre las mejores herramientas para usar para lograr esto? Sé que existen herramientas como Apigee que le permiten probar 1 servicio a la vez, pero nos gustaría una forma de probar todos los servicios con solo presionar un botón.

Answer 1

Colaboré con uno de mis compañeros de trabajo para comenzar el marco PyRestTest por este motivo: https://github.com/svanoort/pyresttest

Aunque puede trabajar con las pruebas en Python, el formato de prueba normal está en YAML.

Conjunto de prueba de muestra para una aplicación REST básica: verifica que las API responden correctamente, verificando los códigos de estado HTTP, aunque también puede hacer que examine los cuerpos de respuesta:

---
- config:
    - testset: "Tests using test app"

- test: # create entity
    - name: "Basic get"
    - url: "/api/person/"
- test: # create entity
    - name: "Get single person"
    - url: "/api/person/1/"
- test: # create entity
    - name: "Get single person"
    - url: "/api/person/1/"
    - method: ''DELETE''
- test: # create entity by PUT
    - name: "Create/update person"
    - url: "/api/person/1/"
    - method: "PUT"
    - body: ''{"first_name": "Gaius","id": 1,"last_name": "Baltar","login": "gbaltar"}''
    - headers: {''Content-Type'': ''application/json''}
- test: # create entity by POST
    - name: "Create person"
    - url: "/api/person/"
    - method: "POST"
    - body: ''{"first_name": "Willim","last_name": "Adama","login": "theadmiral"}''
    - headers: {Content-Type: application/json}

Answer 2

En mi trabajo, hemos creado recientemente un par de suites de prueba escritas en Java para probar algunas API RESTful que creamos. Nuestros Servicios podrían invocar otras API RESTful de las que dependen. Lo dividimos en dos suites.

• Suite 1 - Prueba de cada servicio en aislamiento
  • Burlarse de los servicios de pares que la API depende de usar restito . Otras alternativas incluyen rest-driver , wiremock y wiremock .
  • Prueba el servicio que estamos probando y todos los simulacros se ejecutan en una sola JVM
  • Lanza el servicio en embarcadero

Definitivamente recomendaría hacer esto. Nos ha funcionado muy bien. Las principales ventajas son:

• Los servicios de pares se burlan, por lo que no es necesario realizar ninguna configuración de datos complicada. Antes de cada prueba, simplemente usa restito para definir cómo desea que se comporten los servicios pares, tal como lo haría con las clases en pruebas unitarias con Mockito.
• Puede preguntar a los servicios de pares burlados si fueron llamados. No puede hacer estas afirmaciones tan fácilmente con servicios de pares reales.
• La suite es súper rápida ya que los servicios simulados sirven respuestas pre-enlatadas en la memoria. De modo que podemos obtener una buena cobertura sin que la suite tarde en ejecutarse.
• El conjunto es confiable y repetible, ya que está aislado en su propia JVM, por lo que no hay necesidad de preocuparse por otras suites / personas que se desordenan en un entorno compartido al mismo tiempo que el paquete se está ejecutando y provoca que las pruebas fallen.

• Suite 2 - De punta a punta
  • Suite se ejecuta en un entorno completo implementado en varias máquinas
  • API implementada en Tomcat en el entorno
  • Los servicios de pares son implementaciones completas reales "en vivo"

Este conjunto de aplicaciones requiere que configuremos los datos en servicios de pares, lo que significa que las pruebas generalmente demoran más tiempo en redactarse. En la medida de lo posible, usamos clientes REST para hacer la configuración de datos en servicios pares.

Por lo general, las pruebas en este paquete tardan más tiempo en escribirse, por lo que ponemos la mayor parte de nuestra cobertura en el conjunto 1. Dicho esto, todavía hay un valor claro en este conjunto ya que nuestros simulacros en el conjunto 1 pueden no comportarse del mismo modo que los servicios reales.

Answer 3

Frisby es un marco de prueba REST API basado en node.js y Jasmine que hace que probar los puntos finales API sea fácil, rápido y divertido. http://frisbyjs.com

Ejemplo:

var frisby = require(''../lib/frisby'');

var URL = ''http://localhost:3000/'';
var URL_AUTH = ''http://username:password@localhost:3000/'';

frisby.globalSetup({ // globalSetup is for ALL requests
  request: {
    headers: { ''X-Auth-Token'': ''fa8426a0-8eaf-4d22-8e13-7c1b16a9370c'' }
  }
});

frisby.create(''GET user johndoe'')
  .get(URL + ''/users/3.json'')
  .expectStatus(200)
  .expectJSONTypes({
    id: Number,
    username: String,
    is_admin: Boolean
  })
  .expectJSON({
    id: 3,
    username: ''johndoe'',
    is_admin: false
  })
  // ''afterJSON'' automatically parses response body as JSON and passes it as an argument
  .afterJSON(function(user) {
    // You can use any normal jasmine-style assertions here
    expect(1+1).toEqual(2);

    // Use data from previous result in next test
    frisby.create(''Update user'')
      .put(URL_AUTH + ''/users/'' + user.id + ''.json'', {tags: [''jasmine'', ''bdd'']})
      .expectStatus(200)
    .toss();
  })
.toss();

Answer 4

Implementé muchos casos de automatización basados ​​en REST Assured, un DSL jave para probar un servicio reparador. https://code.google.com/p/rest-assured/

La sintaxis es fácil, admite json y xml. https://code.google.com/p/rest-assured/wiki/Usage

Antes de eso, probé SOAPUI y tuve algunos problemas con la versión gratuita. Además, los casos están en archivos xml que son difíciles de extender y reutilizar, simplemente no me gusta

Answer 5

La automatización de la prueba API, hasta una vez por minuto, es un servicio disponible a través de la API Right . Usted crea sus escenarios de prueba y los ejecuta. Una vez que esas pruebas hacen lo que usted espera, usted puede programarlas. Las pruebas se pueden ''encadenar'' juntas para escenarios que requieren autenticación. Por ejemplo, puede tener una prueba que haga una solicitud de OAuth a Twitter, y cree una ficha compartida que luego podrá usar cualquier otra prueba. Las pruebas también pueden tener criterios de validación adjuntos para garantizar los códigos de estado de HTTP, o incluso una inspección detallada de las respuestas mediante javascript o validación de esquema. Una vez programadas las pruebas, puede hacer que las alertas lo notifiquen tan pronto como una prueba en particular no valide, o se comporte fuera de los rangos establecidos para el tiempo de respuesta o el tamaño de la respuesta.

Answer 6

También puede usar la biblioteca Rest Assured. Para una demostración con script de ejemplo, consulte http://artoftesting.com/automationTesting/restAPIAutomationGetRequest.html

Answer 7

Uno de los problemas de hacer pruebas automatizadas para las API es que muchas de las herramientas requieren que tenga el servidor de la API en funcionamiento antes de ejecutar su conjunto de pruebas. Puede ser una ventaja real contar con un marco de prueba unitario que sea capaz de ejecutar y consultar las API en un entorno de prueba totalmente automatizado.

Una opción que es buena para las API implementadas con Node.JS / Express es usar mocha para pruebas automatizadas. Además de las pruebas unitarias, es fácil escribir pruebas funcionales contra las API, separadas en diferentes suites de prueba. Puede iniciar el servidor API automáticamente en el entorno de prueba local y configurar una base de datos de prueba local. Al usar make, npm y un servidor de compilación, puede crear un objetivo de "prueba de prueba" y una compilación incremental que ejecutará todo el conjunto de pruebas cada vez que se envíe un fragmento de código a su repositorio. Para el desarrollador verdaderamente exigente, incluso generará un buen informe de cobertura de código HTML que le muestra qué partes de su código base están cubiertas por pruebas o no. Si esto suena interesante, aquí hay una publicación de blog que proporciona todos los detalles técnicos.

Si no está utilizando un nodo, cualquiera que sea el marco de prueba de la unidad de hecho para el idioma (jUnit, pepino / capibara, etc.), consulte su soporte para hacer girar los servidores en el entorno de prueba local y ejecutar las consultas HTTP. Si se trata de un proyecto grande, el esfuerzo para obtener pruebas de API automatizadas y la integración continua funcionando dará sus frutos bastante rápido.

Espero que ayude.

Answer 8

Utilicé las clases TestNG y Apache HTTP para construir mi propio marco de prueba REST API, desarrollé este concepto después de trabajar en Selenium durante dos años.

Todo es lo mismo, excepto que debes usar clases Apache HTTP en lugar de clases de Selenium.

pruebe, es muy lindo y bueno, tiene todo el poder para personalizar su marco de prueba a sus posibilidades más completas.

Answer 9

Runscope es un servicio basado en la nube que puede monitorear las API web utilizando un conjunto de pruebas. Las pruebas pueden programarse y / o ejecutarse a través de ganchos web parametrizados. Las pruebas también se pueden ejecutar desde centros de datos de todo el mundo para garantizar que los tiempos de respuesta sean aceptables para la base de clientes globales.

El nivel libre de Runscope admite hasta 10K solicitudes por mes.

Descargo de responsabilidad: soy un defensor de desarrolladores para Runscope.

Answer 10

Usé SOAP UI para pruebas funcionales y automáticas. La interfaz de usuario de SOAP te permite ejecutar las pruebas con solo hacer clic en un botón. También hay una página de prueba de controladores de primavera creada por Ted Young. Usé este artículo para crear pruebas de unidades de descanso en nuestra aplicación.