As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Técnicas de teste para aplicações com tecnologia sem servidor
Há três abordagens principais para executar testes em código de aplicativo sem servidor: teste simulado, teste de emulação e teste na nuvem. Geralmente, é possível encontrar uma combinação dessas abordagens em uso no escopo de um único projeto. Por exemplo, você pode usar testes simulados ao desenvolver seu código localmente, testes de emulação para replicar mais de perto o comportamento do serviço antes da implantação e testes em nuvem como parte de um processo noturno de integração contínua e entrega contínua (CI/CD).
Teste de simulação
O testar de simulação é uma técnica em que você cria objetos de substituição no seu código para simular o comportamento de um serviço na nuvem. Por exemplo, você pode escrever um teste que usa uma simulação do serviço Amazon S3 e pode configurar essa simulação para retornar um objeto de resposta específico sempre que PutObject o método for chamado. Quando o teste é executado, a simulação retorna essa resposta sem chamar o Amazon S3 ou qualquer outro endpoint de serviço.
Esses objetos de substituição geralmente são gerados por uma estrutura de simulação para reduzir a quantidade de implementação necessária para um determinado teste. Algumas estruturas simuladas são genéricas e outras são projetadas especificamente para. AWS SDKs
As simulações, junto com os stubs, se enquadram na categoria mais ampla de falsificações. Os mocks diferem dos emuladores (discutidos posteriormente nesta seção) porque os mocks geralmente são criados ou configurados por um desenvolvedor como parte do código de teste, enquanto os emuladores são aplicativos autônomos que expõem APIs (como REST APIs) da mesma maneira que os sistemas que eles emulam.
As vantagens de usar simulações incluem o seguinte:
-
Os mocks podem simular serviços de terceiros que estão além do controle de seu aplicativo, como APIs provedores de software como serviço (SaaS), sem precisar de acesso direto a esses serviços.
-
As simulações também são úteis para testar condições de falha, especialmente quando essas condições (como interrupções de serviços) são difíceis de simular.
-
Assim como os emuladores, as estruturas simuladas podem fornecer desenvolvimento local rápido depois de configuradas.
-
As simulações podem fornecer um comportamento substituto para praticamente qualquer tipo de objeto. Portanto, as estratégias de simulação podem criar cobertura para uma variedade mais ampla de serviços do que os emuladores.
-
Quando novos recursos ou comportamentos são disponibilizados, os testes simulados podem reagir mais rapidamente usando (ou recorrendo a) uma estrutura de simulação genérica, que pode simular os novos recursos assim que o AWS SDK atualizado estiver disponível.
O teste com simulação tem as seguintes desvantagens:
-
As simulações geralmente exigem uma quantidade significativa de esforços de definição e configuração, especificamente na tentativa de determinar valores de retorno de diferentes serviços para simular respostas adequadamente.
-
Como as simulações são escritas ou configuradas pelos desenvolvedores que escrevem os testes, essa é uma responsabilidade adicional para os desenvolvedores.
-
Talvez você precise ter acesso à nuvem para entender APIs e retornar os valores dos serviços.
-
As simulações também podem ser difíceis de manter, pois elas exigem atualizações sempre que as assinaturas simuladas da API de nuvem mudam, os esquemas de valor de retorno evoluem ou a lógica do aplicativo testada é estendida para fazer chamadas para novas. APIs Essas mudanças criam uma workload adicional de desenvolvimento de testes para os desenvolvedores.
-
Os testes simulados podem ser aprovados localmente, mas falhar na nuvem porque simulam — em vez de replicar — o comportamento de serviços reais, deixando os problemas específicos do ambiente sem serem detectados.
-
Estruturas simuladas, como emuladores, não conseguem detectar violações de políticas AWS Identity and Access Management (IAM), limites de cota de serviço ou restrições de tamanho de carga, nem acionam serviços auxiliares, como a Amazon AWS CloudTrail ou a Amazon CloudWatch, GuardDuty que podem afetar o comportamento do aplicativo em um ambiente implantado.
-
Embora as simulações sejam melhores para simular o que um aplicativo fará quando a autorização falhar ou uma cota for excedida, o teste simulado não pode determinar qual resultado realmente ocorrerá quando o código for implantado no ambiente de produção.
Teste de emulação
O teste de emulação é ativado por aplicativos executados localmente, conhecidos como emuladores, que se assemelham. Serviços da AWS Os emuladores APIs são semelhantes aos da nuvem e fornecem valores de retorno semelhantes. Eles também podem simular mudanças de estado iniciadas por chamadas de API. Por exemplo, um emulador do Amazon S3 pode armazenar um objeto no disco local quando o PutObject método é chamado. Quando GetObject é chamado com a mesma chave, o emulador lê o mesmo objeto do disco e o retorna.
As vantagens do teste de emulação incluem:
-
Ele fornece um ambiente familiar para desenvolvedores acostumados a desenvolver código exclusivamente em um ambiente local. Por exemplo, se você estiver familiarizado com o desenvolvimento de um aplicativo de n camadas, talvez tenha um mecanismo de banco de dados e um servidor web, semelhantes aos executados em produção, em execução em sua máquina local para fornecer capacidade de teste rápida, local e isolada.
-
Ele não exige nenhuma alteração na infraestrutura de nuvem (como contas de desenvolvedores na nuvem), por isso é fácil de implementar com os padrões de teste existentes. O teste de emulação oferece os benefícios das iterações rápidas características do desenvolvimento local.
No entanto, os emuladores apresentam várias desvantagens:
-
Eles geralmente são difíceis de configurar e replicar, especialmente quando são usados como parte de CI/CD pipelines. Isso talvez aumente a workload e os esforços de manutenção da equipe de TI ou dos desenvolvedores que gerenciam suas próprias instalações de software.
-
Os recursos emulados APIs geralmente ficam atrasados em relação às mudanças nos serviços e podem impedir a adoção de novos recursos até que o suporte seja adicionado.
-
Os emuladores podem exigir suporte, atualizações, correções de erros ou aprimoramentos de paridade de recursos, os quais são de responsabilidade do autor do emulador (que geralmente é uma empresa terceirizada).
-
Testes que dependem de emuladores podem fornecer resultados bem-sucedidos localmente, mas podem falhar na nuvem devido a interações com outros aspectos, AWS como políticas e cotas do IAM, que geralmente não são emuladas.
-
Alguns Serviços da AWS não têm emuladores disponíveis, portanto, se você depende apenas da emulação, talvez não tenha uma opção de teste satisfatória para partes do seu aplicativo.
Testes na nuvem
Testar na nuvem é o processo de executar testes em código implantado em um ambiente de nuvem em vez de em um ambiente de desktop. O valor da teste na nuvem aumenta com o desenvolvimento da aplicação nativa de nuvem. Por exemplo:
-
Você pode executar testes na nuvem com os recursos mais recentes APIs e de serviço, garantindo que seus testes reflitam os valores e comportamentos de retorno mais recentes à medida que AWS continua lançando novos serviços e recursos.
-
Os testes podem abranger políticas do IAM, cotas de serviço, configurações e todos os serviços.
-
Seu ambiente de teste na nuvem é mais parecido com o ambiente de runtime de produção, portanto, os testes que você executa na nuvem provavelmente alcançarão os resultados mais consistentes à medida que avançam nos ambientes.
As desvantagens dos testes na nuvem incluem:
-
As implantações em ambientes de nuvem geralmente levam mais tempo do que as implantações em ambientes de desktop. Ferramentas como AWS Serverless Application Model (AWS SAM) Accelerate, modo de observação do AWS Cloud Development Kit (AWS CDK) e SST
ajudam a diminuir a latência envolvida nas iterações de implantação na nuvem. -
Os testes na nuvem podem gerar custos adicionais de serviço, diferentemente dos testes locais, que usam seu ambiente de desenvolvimento local.
-
Os testes na nuvem podem ser menos viáveis se você não tiver acesso à Internet de alta velocidade.
-
Em setores regulamentados, as políticas de segurança corporativa podem restringir o acesso do desenvolvedor aos ambientes de nuvem, dificultando ou impossibilitando a execução de testes em nuvem como parte de um fluxo de trabalho de desenvolvimento local.
-
Os limites do ambiente geralmente são traçados no nível da pilha em contas compartilhadas para ambientes de desenvolvedores, às vezes usando estratégias do tipo namespace, como o uso de prefixos para identificar a propriedade. Para ambientes de pré-produção e de produção, limites geralmente são estabelecidos no nível da conta para isolar as workloads dos problemas de vizinhos barulhentos, oferecer suporte a controles de segurança de privilégio mínimo e proteger dados confidenciais. A exigência de criar ambientes isolados pode sobrecarregar DevOps as equipes, especialmente se elas estiverem em uma empresa que tenha controles rígidos sobre contas e infraestrutura.
