Usando mais de uma asserção em testes automatizados de API
Quando estamos testando uma API manualmente, em uma única requisição, fazemos diversas validações. Status code, headers e body são alguns dos pontos que validamos, mas quando estamos falando de automação, qual a quantidade de asserções que devemos ter nesta mesma requisição?
As boas práticas nos mostram que devemos ter apenas uma asserção para cada teste, isso facilita na manutenção e nos mostra exatamente o que deu errado caso esse teste falhe. Isso é muito válido para testes unitários, mas quando estamos falando em um contexto de testes de APIs, será que essa abordagem continua sendo válida?
As asserções de um teste automatizado são executadas na ordem em que são inseridas no código, portanto, se você tem quatro asserções em um teste e ele passa, você garante que os quatro pontos validados naquela resposta estão funcionando conforme o esperado. Mas o que acontece quando o teste não passa e o resultado mostra que falhou na asserção dois? Será que a asserção três e quatro foram executadas?
Em algumas bibliotecas de teste como por exemplo o JUnit, por default, caso ocorra falha em uma asserção, as seguintes não serão executadas. Mas se elas não foram executadas, como saber se aquele ponto da resposta está funcionando conforme o esperado?
Existem grandes discussões sobre qual a quantidade ideal de asserções em um teste, poderia dizer que existem dois grandes grupos. No grupo um, pessoas que concordam em ter apenas uma asserção, e no grupo dois, pessoas que dizem que dependendo do contexto, você poderia ter várias asserções em um único teste.
E você, em qual grupo se encaixa?
Se você era um dos que escolheu entrar no grupo dois, mas depois de ler as boas práticas mudou de ideia e pensa em entrar para o grupo um, isso é normal, neste artigo te daremos insumos necessários para uma escolha definitiva e mais assertiva de em qual grupo ficar.
Portanto, qual é o Problema?
Queremos fazer testes automatizados de API Rest, validando diversos pontos da resposta em um único teste, e caso esse teste falhe, que nos mostre todas as asserções negativas e não somente a primeira que quebrou. Isso evitaria ter de fazer várias vezes a mesma requisição com os mesmos parâmetros, o que poderia deixar nossa suíte de teste mais lenta e custosa.
Então , se colocamos 3 asserções em um teste e a primeira falha, seja por um problema no código de teste ou da aplicação, será preciso consertar o que nos foi apresentado como falha, rodar o teste novamente para ter a certeza que tudo está ok, e caso a segunda asserção quebre, será necessário repetir o processo e assim sucessivamente até que todas as asserções passem…Pode ser um pouco trabalhoso, não?
E então, qual foi a solução?
Procuramos uma forma que, a cada vez que o teste rodasse, todas as asserções fossem executadas independente do resultado. Assim teríamos uma informação mais completa caso o teste falhasse.
Neste caso vamos utilizar Java + Rest Assured, mas vale lembrar que esta abordagem pode ser executada em qualquer outra linguagem (encontramos solução similar utilizando Ruby+Rspec).
Procuramos na documentação do Rest Assured e, EUREKA! A solução estava bem na nossa frente.
A documentação do Rest Assured mostra que, usando o método “expect” ao invés do “then”, todas as asserções serão executadas mesmo que uma falhe, Isso não é demais!?
Abaixo vamos demonstrar o código de teste e seu resultado utilizando esta abordagem. No nosso teste queremos validar o statusCode e dois valores retornados na resposta da API.
Neste caso, as três asserções falharam propositalmente para confirmar a solução:
Como podemos ver, foi apresentado no log o resultado de todas as asserções.
Listaremos abaixo, algumas vantagens e desvantagens que percebemos ao usar esse tipo de abordagem.
Vantagens
- Rapidez na escrita dos testes;
- Feedback rápido na execução dos testes;
- Ver no log todas as asserções que falharam (caso o teste venha a quebrar);
- Se falando de API, não vamos precisar fazer várias vezes a mesma requisição;
- Evita repetição de código.
Desvantagens
- Teste fica mais sensível a falha durante alguma alteração do serviço devido à grande quantidade de asserts;
- Pode exigir uma manutenção maior;
- A execução do teste pode ficar mais lento.
E depois de ver tudo isso, em qual grupo você se encaixa?
Conclusões finais
Ainda existem muitas discussões sobre usar uma ou mais asserções em um teste, mas usando este tipo de abordagem, seja qual for a linguagem de programação, é possível validar vários atributos da resposta da requisição em um único teste e ainda ver no resultado da execução todos os que falharam, facilitando assim a nossa validação, sem precisar repetir várias vezes as execuções quando apenas uma das asserções falha e é corrigida.
No entanto, você precisa entender seu contexto e identificar se faz sentido validar vários elementos ao mesmo tempo, pois como em grande parte das soluções tecnológicas, existem vantagens e desvantagens de usar esta abordagem, cabe você e ao time decidirem juntos qual estratégia utilizar.
Este artigo surgiu quando o Tiago e o Ismael, alunos do curso Descomplicando Testes de API Rest (DTAR) e autores deste artigo, questionaram se deveríamos ou não incluir mais de uma asserção em um teste e como seria possível exibir o resultado de todas as asserções que quebraram. Queremos agradecer o Júlio de Lima, Antonio Montanha por nos incentivarem a escrever o artigo e o todos editores e revisores/as do DTAR na revisão deste conteúdo.
