What are Service Acceptance Tests?

Testes de Aceitação: Entendendo os Tipos e Importância

O que são Testes de Aceitação?

• Os testes de aceitação dos serviços são semelhantes aos testes de aceitação tradicionais, mas focam na interação com o sistema através do servidor, em vez da interface gráfica.

• A figura apresentada ilustra a diferença entre testes de aceitação de UI (interface do usuário) e testes que exercitam o sistema via servidor.

• Esses testes envolvem enviar requisições ao servidor e observar as respostas, permitindo uma análise mais direta do funcionamento do sistema.

Por que Precisamos de Dois Tipos de Teste?

• É crucial garantir que o sistema funcione bem tanto para usuários humanos quanto para outros sistemas que utilizam seus serviços.

• Exemplos como Twitter mostram como um sistema pode ser acessado por interfaces gráficas ou por outros sistemas automatizados, como ferramentas de análise.

• Sistemas maiores frequentemente consistem em múltiplos subsistemas interagindo entre si, tornando essencial testar ambos os tipos para assegurar a funcionalidade completa.

Contexto e Necessidade dos Testes

• A necessidade dos testes deve ser avaliada no contexto específico; se um sistema é usado apenas por interfaces gráficas, a necessidade de testes de aceitação do serviço pode ser reduzida.

• Além da interação com outros sistemas, os testes ajudam na localização precisa de problemas quando ocorrem falhas nos testes tradicionais.

Localizando Problemas com Testes

• Quando um teste falha no cliente, não é claro onde está o problema. Os testes de aceitação do serviço podem ajudar a restringir essa busca.

• Se um teste no cliente falha e outro no servidor também falha, isso indica que o problema provavelmente reside no servidor.

• Caso o teste do servidor passe enquanto o teste do cliente falha, isso sugere que a questão pode estar na comunicação ou no código do cliente.

Exemplificação dos Testes

Análise do Sistema de Registro de Alunos

Interação com a Interface Gráfica

• O foco inicial é na interface gráfica do sistema, onde se busca verificar a existência de um aluno específico (Paulo, CPF 683) no registro.

• A análise se desloca da interface gráfica para o estado interno do servidor, enfatizando que as verificações são feitas em dados armazenados e não apenas na apresentação visual.

Descrição dos Cenários

• A descrição dos passos segue o estilo Cucumber, referenciando o estado interno do sistema ao invés da interface gráfica.

• Os cenários não mencionam ações como clicar ou preencher campos; em vez disso, focam no envio de requisições ao servidor e na análise das respostas recebidas.

Requisições ao Servidor

• O primeiro passo envolve enviar uma requisição GET ao servidor para verificar a presença do aluno com CPF 683.

• A URL base é utilizada para compor a requisição, mas não há garantias sobre seu sucesso ou entrega ao servidor.

Análise da Resposta

• O resultado da requisição é uma promessa que deve ser analisada; se bem-sucedida, retorna um corpo de mensagem que será verificado.

• O corpo da resposta deve incluir um objeto JSON contendo o atributo CPF. Se esse atributo estiver presente, indica que já existe um aluno cadastrado.

Verificação das Condições

• A implementação verifica se o corpo retornado não inclui o CPF 683, confirmando assim que nenhum aluno está registrado com esse número.

• Assume-se que o sistema está sempre em seu estado inicial para cada teste; caso contrário, seria necessário realizar ações adicionais antes das verificações.

Estado Inicial e Pré-condições

• Em situações onde o sistema não é reiniciado entre os testes, pode ser necessário forçar a remoção de registros existentes antes de realizar novas requisições.

• Um diagrama ilustra como os testes podem exigir ações iniciais para garantir que as pré-condições sejam válidas antes das verificações finais.

Conclusão dos Testes