Rest-Assured: Como criar testes automáticos para API REST?

API_MATERANo último post que escrevi, Como testar uma API REST? abordei os pontos que devem ser levados em consideração durante os testes de uma API REST. O objetivo deste novo post é mostrar como é fácil automatizar esse tipo de teste usando o framework Rest-Assured.

Rest-Assured é um framework open-source que possui suporte para automatizar os métodos GET, POST, PUT, DELETE, HEAD, OPTIONS e TRACE de uma API e permitir fazer validações no header, body e schema da resposta.

Neste post será mostrado como criar testes automáticos dos métodos GET e POST.

Caso você utilize Maven (caso não utilize, veja aqui algumas alternativas para configurar o projeto), o primeiro passo é criar um projeto Java e adicionar as seguintes dependências:

<dependencies>
  <dependency>
      <groupId>com.jayway.restassured</groupId>
      <artifactId>rest-assured</artifactId>
      <version>2.4.1</version>
      <scope>test</scope>
  </dependency>
  <dependency>
      <groupId>com.jayway.restassured</groupId>
      <artifactId>json-path</artifactId>
      <version>2.4.1</version>
  </dependency>
  <dependency>
      <groupId>com.jayway.restassured</groupId>
      <artifactId>json-schema-validator</artifactId>
      <version>2.4.1</version>
      <scope>test</scope>
  </dependency>
  <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
  </dependency>		
</dependencies>
Listagem 1 – Dependências para testes automáticos com Rest-Assured
  • rest-assured: Biblioteca do framework rest-assured;
  • json-path: Biblioteca responsável por ler as respostas das mensagens retornadas pela API;
  • json-schema-validator: Biblioteca responsável por validar se a estrutura da resposta está correta;
  • junit: Biblioteca que auxilia na escrita de testes automatizados.

Depois de adicionado as dependências, crie uma classe de testes JUnit. Caso você esteja utilizando Eclipse, basta criar um novo arquivo do tipo JUnit Test Case:

junit_test_case

Figura 1 – Criando uma classe  “JUnit Test Case”  no Eclipse

Depois de criada a classe, faça o importe das seguintes bibliotecas:

import static com.jayway.restassured.RestAssured.*;
import static org.hamcrest.Matchers.*;
import static com.jayway.restassured.module.jsv.JsonSchemaValidator.*;
import org.junit.Test;
Listagem 2 – Importação das bibliotecas no projeto

No construtor da classe adicione a URL do serviço que será automatizado. No nosso exemplo a URL a ser utilizada é de um serviço disponibilizado pelo Postman.

public class TestesAPI {
	
	public TestesAPI(){
		baseURI = "http://dump.getpostman.com/blog/users";
	}
Listagem 3 – Construtor da classe contendo a URL do serviço REST

O próximo passo é criar um método que validará o envio de uma requisição do tipo POST. O serviço que vamos usar como exemplo, é um serviço que ao receber um JSON com os atributos usuário e senha, retornará uma mensagem informando que o usuário foi criado com sucesso. Abaixo segue uma imagem do que é enviado e recebido pela API quando fazemos o teste manualmente:

metodo_post

Figura 2 – Execução manual do serviço REST usando o método POST

Vamos utilizar no nosso método Java a estrutura Given, When e Then que basicamente é a forma de descrever um teste nos conceitos ágeis. O método ficará da seguinte forma:

@Test
	/*Chama o serviço pelo metodo POST*/
	public void testCriaUsuario() {
		String myJson = "{\"username\":\"abhinav\",\"password\": \"abc\"}";
    	
         given()
           .contentType("application/json")
    	   .body(myJson)
    	 .when()
    	   .post("/")
    	 .then()
    	   .statusCode(200)
    	   .body("message", containsString("User created successfully"));	 
	}
 Listagem 4 – Código para validar os dados do serviço quando enviado uma requisição do tipo POST

Então o que o código acima faz? É muito simples, ele valida se a resposta recebida ao passar terminada informação para um serviço REST é a resposta esperada.

Em outras palavras: Dado (given) uma URL (o método Given entende que a URL a ser chamada é à definida no construtor da classe) passando no body um JSON com os atributos username e password, quando (when) for por meio do método POST, então (then) o resultado esperado é que o status de retorno seja igual a 200 e que o atributo message enviado no retorno contenha a frase “User created successfully” indicando que o usuário foi criado com sucesso. Muito simples, né? 🙂

É importante lembrar que o método deve conter a anotação @Test para indicar que se trata de um teste automático.

Esse foi um simples exemplo de como validar o retorno de um método do tipo POST. Agora iremos ver quais validações podem ser feitas para uma requisição do tipo GET. O serviço REST que iremos usar como exemplo é o mesmo serviço do código anterior, porém ao chamar a URL com o método GET e passando o parâmetro 1 é retornado as informações do usuário que possui o ID igual a 1. Veja abaixo o retorno do serviço quando o mesmo é chamado manualmente:

metodo_get

Figura 3 – Execução manual do serviço REST usando o método GET

O próximo passo é criarmos um novo método na nossa classe de testes chamado “TestConsultaUsuario” onde será validado se os dados do usuário estão corretos e se a reposta veio com a estrutura esperada conforme definido no schema do serviço.

@Test
	/*Chama o serviço pelo metodo GET*/
	public void testConsultaUsuario() {
		
		 given()
		 .when()
		    .get("/1")
		 .then()
		    .statusCode(200)
		    .body("created_at", is(1396006450))
		    .body("id", is(1))
		    .body("token", equalTo("JbaGIjDQMyvbTyRNsAqmOMijTnpUez"))
		    .body("username", equalTo("prakhar1989"))
		    .assertThat()
		       .body(matchesJsonSchemaInClasspath("schema_exemplo.json"));
	}
Listagem 5 – Código para validar os dados do serviço quando enviado uma requisição do tipo GET

Utilizando a mesma estrutura given, when e then do método anterior, basicamente o que o código faz é: Dado (given) uma URL, quando (when) a requisição for feita usando o tipo GET, passando o parâmetro 1, então (then) é esperado que o status de retorno seja igual a 200 e que os atributos created_at, id, token e username enviados no body do response, contenham as informações iguais as definidas no código acima.

E por último é validado na linha 15 se a estrutura da resposta corresponde (matches) com o schema definido pelo serviço. Para que o teste seja capaz de fazer essa validação, é necessário inserir o arquivo de schema dentro do projeto de teste conforme a imagem abaixo e no código fazer referência ao arquivo (linha 15 do código):

projeto_schema

Figura 4 – Estrutura do projeto, exibindo onde deve ser inserido o arquivo de schema

O schema do serviço utilizado como exemplo é:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "id": "http://dump.getpostman.com/blog/users/1",
  "type": "object",
  "properties": {
    "created_at": {
      "id": "http://dump.getpostman.com/blog/users/1/created_at",
      "type": "integer"
    },
    "id": {
      "id": "http://dump.getpostman.com/blog/users/1/id",
      "type": "integer"
    },
    "token": {
      "id": "http://dump.getpostman.com/blog/users/1/token",
      "type": "string"
    },
    "username": {
      "id": "http://dump.getpostman.com/blog/users/1/username",
      "type": "string"
    }
  },
  "required": [
    "created_at",
    "id",
    "token",
    "username"
  ]
}
Listagem 6 – Schema do JSON usado como exemplo

Pronto!! Difícil? Não 🙂 . Com poucos passos criamos testes automatizados para um serviço REST.

Agora para executar os testes basta clicar com o botão direito no projeto e clicar no menu “Run As > JUnit Test“.

É possível fazer o download do código apresentado neste post clicando aqui.

Esses foram exemplos bem simples, mas um bom inicio para quem quer começar a automatizar testes de APIs REST.

Por MONISE COSTA

Formada em Sistemas de Informação pela PUC Campinas, MATERANA desde 2011. Apaixonada pela área de TI, Analista de Requisitos na maior parte do tempo e desenvolvedora Java/Android por lazer.

Postado em: 28 de dezembro de 2015

Confira outros artigos do nosso blog

Matera participa da 9ª edição do meetup DevTests Campinas

03 de setembro de 2018

Ariane Ferreira Izac

Teste de mutação com PITest

24 de agosto de 2018

Julio Cesar Consolini

Introdução ao Dev-Test Pairing

13 de junho de 2018

Caio Rizolli

Falando sobre Teste de Intrusão (ou PenTest)

03 de abril de 2018

Jacqueline Costa

Deixe seu comentário