No último encontro da Comunidade de Prática de Qualidade de Software, compartilhei com os colegas meus conhecimentos sobre RestAssured, uma biblioteca que permite testar serviços Rest em Java. Ela provê uma maneira de criar chamadas HTTP sendo executada em conjunto com o framework JUnit, que permite estruturar os testes.
Enquanto utilizamos o JUnit para definir os métodos de teste, através da anotação @Test, o RestAssured efetua chamadas HTTP, obtém o retorno do serviço e realiza validações a partir da resposta. Neste artigo, vou explicar como utilizar tal biblioteca, na prática.
O que testar e como testar?
A estrutura do RestAssured trabalha no formato de BDD (Behavior Driven Development), ele faz chamadas para o serviço utilizando a sintaxe given, when e then. No given passamos as pré-condições como, por exemplo, token de autenticação e body; no when efetuamos a chamada para o método a ser testado, passando parâmetros quando forem necessários; e o then tem como função trabalhar com os retornos da requisição, extraindo respostas e efetuando assertivas.
Quando falamos em testes de serviços, os itens básicos para validação são o status code, body (onde podemos validar mensagens e valores de atributos), autenticação, permissões de acesso, content type, entre outras. Cada contexto terá diferentes cenários a serem testados, mas utilizaremos como base esses itens para validação. Tais validações podem ser realizadas por meio de recursos do JUnit como o AssertEquals(), por exemplo, ou com a biblioteca Hamcrest que oferece recursos que possibilitam escrever testes mais específicos.
Primeiros passos
1. Adicionar as dependências do RestAssured e JUnit ao arquivo POM do projeto:
2. Criar a estrutura dos pacotes de teste: quando estamos aprendendo geralmente configuramos a URL base e passamos o payload dentro da mesma classe. Aqui o exemplo é de uma estrutura onde temos dados, testes e utilidades em pacotes separados, deixando os testes mais visíveis e organizados.
3. Fazer as importações estáticas: quando começamos a digitar os códigos do RestAssured, automaticamente a IDE irá sugerir os imports, mas através da documentação do RestAssured recomenda-se fazer as importações estáticas para um uso mais efetivo.
4. Criar a classe de configuração da URL base: podemos configurar a porta em que a API está rodando e o caminho base da API através dessa classe, que será posteriormente estendida para as classes de teste, tornando necessário informar apenas o endpoint em cada método de teste, uma vez que o caminho base já foi definido.
Iniciando os testes
1. Obtendo token: neste exemplo, estamos fazendo uma requisição onde o payload é enviado através do body ao fazer o post, o token será extraído e armazenado na variável tokenAdm. Neste método nenhum teste está sendo efetuado, apenas a extração do token para posterior utilização.
2. Primeiro teste: no given(). estamos passando o token extraído anteriormente para obter autorização de cadastro e o payload está sendo passado diretamente no body. No when estamos chamando somente o endpoint a ser testado, pois a classe que contém o caminho base foi estendida. Por fim no then(). o statusCode() está sendo validado.
3. Passando os dados através de um Map na classe dados para posterior substituição do payload na classe de testes:
4. Efetuando o mesmo teste do passo 2, porém recebendo no body o payload da classe Dados:
5. Neste último exemplo está sendo validada a chamada para um método GET e, além do statusCode(), está sendo verificado se o retorno da resposta contém os valores informados através do método containsString().
Ao final da CoP de Qualidade de Software, o colega Henrique Rodrigues Vieira ainda complementou dizendo que os responses podem ser extraídos nos formatos de objeto e json, o que possibilita fazer as assertivas com base no response completo. Também explicou que o dataprovider pode ser utilizado para montar o payload a fim de obter testes repetitivos.
