What are non acceptance service tests?

Testes de Serviço Não de Aceitação

Introdução aos Testes de Serviço

• O foco é ilustrar testes de serviço que não são de aceitação, utilizando terminologia e dimensões de classificação previamente discutidas.

• Os testes exercitam diretamente os serviços do servidor do sistema, sem depender de classes auxiliares ou agulhas.

Características dos Testes Não de Aceitação

• A designação "não aceitação" indica que esses testes não garantem a aceitação da entrega do sistema, pois não derivam diretamente de requisitos explícitos.

• Os requisitos verificados são implícitos e necessários para atender aos requisitos explícitos solicitados pelos stakeholders.

Diferença entre Requisitos Explícitos e Implícitos

• A distinção entre os dois tipos de requisitos é crucial: enquanto os explícitos são documentados em cenários, os implícitos são baseados nas necessidades percebidas pelo desenvolvedor.

• Na disciplina abordada, o termo "teste de serviço não aceitação" também se refere a testes funcionais que podem ser unitários, de integração ou do sistema.

Tipos e Garantias dos Testes

• A garantia dos testes pode ser por regressão (assegurando que funcionalidades existentes não foram quebradas) ou smokey (verificando funcionalidades básicas).

• A complexidade do teste determina qual tipo é mais adequado; um teste complexo pode não ser apropriado como um teste smokey.

Exemplo Concreto e Implementação

• Um exemplo prático ilustra como enviar uma requisição ao servidor para verificar se retorna uma lista vazia, algo que o desenvolvedor deseja validar.

• A implementação é similar à dos testes de aceitação, mas com a diferença fundamental na origem dos requisitos verificados: explícita versus implícita.

Verificação da Resposta da Requisição

• O teste verifica se a resposta da requisição está vazia. Se houver problemas na requisição, isso deve resultar em falha no teste.

• O código enviado realiza verificações específicas sobre o corpo da resposta para garantir que as condições esperadas sejam atendidas.

Tratamento das Respostas no Código

• O código implementa promessas para lidar com respostas assíncronas. Se a promessa for satisfeita, executa funções específicas para verificar o resultado.

• Caso a requisição falhe ou retorne dados inesperados (diferentes da lista vazia), o teste será considerado quebrado.

Conclusão sobre o Espectro do Teste

• O espectro do teste abrange tanto situações em que a resposta chega quanto aquelas em que ela falha.

Estrutura e Funcionalidade de Testes em Serviços

Introdução aos Testes

• A cláusula inicial especifica um teste, enquanto o describe define uma suíte de testes relacionados. As strings não estão conectadas a requisitos específicos, diferentemente dos testes de aceitação anteriores.

Exemplos de Testes

• O primeiro teste retorna uma lista vazia de alunos, documentando a intenção do teste sem conexão com cenários ou requisitos.

• Um segundo exemplo verifica se o serviço de cadastro aceita apenas objetos JSON do tipo aluno como entrada.

Verificação e Respostas do Servidor

• O teste envia uma requisição em formato JSON para verificar se o servidor realiza a validação correta dos dados recebidos.

• Se a requisição falhar ao enviar um objeto inválido (sem todos os campos necessários), deve gerar um erro.

Requisitos e Garantias do Desenvolvedor

• O teste assegura que o servidor rejeita entradas inválidas, garantindo que as verificações necessárias sejam realizadas pelo sistema.

• Essa abordagem fornece segurança ao desenvolvedor, que espera que o servidor valide corretamente os dados antes da execução.

Configuração e Limpeza nos Testes

• A cláusula beforeAll é utilizada para configurar o ambiente antes da execução dos testes, como iniciar o servidor.

• É possível ter setups únicos para toda a suíte ou configurações específicas para cada teste usando beforeEach.

Execução e Limpeza Pós-Teste

• Após todos os testes serem executados, pode-se usar afterAll para encerrar processos como derrubar o servidor.

Estrutura e Execução de Testes em Código

Limpeza e Requisições Específicas

• A limpeza necessária para um setup específico deve ser implementada no código antes de enviar a requisição, garantindo que o ambiente esteja adequado para o teste.

• Após enviar a requisição, é importante realizar uma nova limpeza ao final do código, assegurando que as ações executadas não afetem testes subsequentes.

Diferenças entre Testes de Aceitação e Propriedades

• O código discutido executa diretamente os serviços do sistema a ser testado, diferentemente dos testes de aceitação que são baseados em cenários específicos.