Como verificar a cobertura de testes de APIs REST
Algumas vezes, no projeto em que estamos inseridos na empresa, precisamos passar para o time uma clareza sobre o que está sendo implementado nos testes automatizados de API REST ou quanto da API está coberta pelos testes.
Existe uma forma de calcular a cobertura de testes, que se baseia nos critérios de cobertura de entrada (Input Coverage) e cobertura de saída (Output Coverage).
Neste artigo vou te mostrar como é realizado o cálculo da cobertura de testes de uma forma simples e objetiva, assim você poderá calcular a cobertura de seus testes, caso ache necessário.
Em seguida, passarei por alguns critérios para explicar como calcular sua cobertura.
Path Coverage (input)
Verifica a cobertura da suíte de testes de acordo com os endpoints que a API possui. Este critério é importante, pois ao receber uma solicitação, o programa pode executar caminhos diferentes, então precisamos garantir que os endpoints da API REST estão cobertos pelos testes.
A análise é realizada pela quantidade de URI( URL + URN (Resource name)) que a API possui (se for a mesma URI para métodos diferentes, considera-se apenas um).
O ideal é realizar ao menos uma requisição para verificar cada endpoint.
Se verificar a imagem do swagger abaixo, podemos notar 13 endpoints diferentes:
Suponha que a automação desta API tenha apenas 6 desses endpoints implementados, mas a API possui 13 endpoints.
Para calcular a cobertura: quantidade de testes automatizados / quantidade de endpoints na API REST.
Então 46% dos testes de path estão cobertos pela automação.
Operator Coverage (input)
Confere a cobertura de testes de todos os métodos existentes na API REST (GET, POST, PUT, DELETE…).
O swagger abaixo tem um total de 19 operações:
Então, deve-se verificar quais métodos da API foram cobertos pela automação de testes. Vamos supor que dezesseis métodos tiveram testes automatizados implementados.
Para calcular a cobertura: quantidade de operações da API estão automatizados/ quantidade total de operações da API REST.
Então temos 84% dos testes de operações cobertos.
Parameter Coverage (input)
Verifica a cobertura de uma suíte de testes conforme os parâmetros existentes em cada método da API.
Para calcular a cobertura:
Para atingir 100% de cobertura de testes é necessário testar todos os parâmetros de entrada de cada operação pelo menos uma vez. Realizar a combinação de todos os parâmetros é desejável, mas não estritamente necessário para chegar a 100% de cobertura.
Suponha que a API tenha um total de 5 parâmetros, e na automação da API os 5 parâmetros foram cobertos.
Quantidade total de parâmetros cobertos na suítes de testes / quantidade total de parâmetros nos métodos da API.
Parameter Value Coverage (input)
Confere a cobertura da suíte de testes de parâmetros booleano e enum nas operações (se existirem).
Para calcular a cobertura:
Quantidade total de valores diferentes enviados / quantidade total de valores que podem assumir.
Para atingir 100% de cobertura cada parâmetro booleano e enum deve assumir todos os valores possíveis.
Content-Type Coverage (input e output)
Verifica a cobertura de testes automatizados onde o content-type está sendo exibido em cada endpoint, ou seja, se for demonstrado nas opções do content-type de envio application/json e um application/xml, então duas opções do parâmetros de envio deveriam ser cobertas.
Também devem ser verificadas as opções do content-type da resposta:
Para calcular a cobertura:
Quantidade total de content-type em cada operação cobertos pela suíte de testes / Quantidade total de content-type em todas as operações da API.
Suponha a API possua as operações POST, PUT, GET e DELETE. POST e PUT possuem cada um 2 opções de content-type, logo a API possui um total de 4 content-type a serem cobertos. A automação cobriu apenas uma opção, no POST e uma opção, no PUT. Sendo assim:
Operation Flow (input)
Este critério mede um conjunto de testes de acordo com as sequências de operações que é executado.
Por exemplo:
Fluxo1: Post-Get(id)
Fluxo2: Post-Put
Fluxo3: Post-Delete
Fluxo4: Post-Get(Query)
Se todos os fluxos estiverem implementados no teste automatizado, então a API Rest está 100% coberta pela automação.
Porém se é possível criar 4 tipos de fluxos, mas sua automação possui apenas um, por exemplo, criação (Post) e consulta (Get id), então terás apenas 25% de cobertura.
Response Properties Body Coverage (Output)
Este critério mede os parâmetros no corpo da resposta, então deve ser verificado se todas as propriedades da resposta estão cobertas pelo teste.
Para calcular a cobertura deve-se dividir o número total de todas as propriedades de todos os objetos que pode ser obtido na resposta da API, pelo número de propriedades da resposta que os testes estão cobrindo.
Status Code Coverage (Output)
Este critério verifica quais status codes existentes em cada endpoint estão cobertos pelos testes.
Suponha que a API tenha um total de 25 status code, e na automação da API apenas 15 status code foram cobertos.
Portanto, para atingir 100% da cobertura de testes, todos os status codes de cada operação deve estar implementado nos testes.
Realizar o levantamento dos critérios de cobertura é importante, pois te dá um norte para saber o quão efetivo os testes automatizados estão sendo. Será que todos os paths da sua API estão cobertos? Será que não é possível atingir 100% de cobertura de parâmetros de entrada dos métodos? Comenta aí, o que você achou desta metodologia ou se você aplicaria e mostraria a cobertura de testes para o seu time.
Referências
- Test Coverage Criteria for RESTful Web APIs - Alberto Martin-Lopez, Sergio Segura e Antonio Ruiz-Cortés
