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 à execução de testes em código de aplicações com tecnologia sem servidor: teste de simulação, teste na nuvem e teste de emulação. Geralmente, é possível encontrar uma combinação dessas abordagens em uso no escopo de um único projeto. Por exemplo, é possível usar testes de simulação ao desenvolver seu código localmente, mas seu código pode ser testado na 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 CreateObjecto 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 de simulação podem possibilitar o 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 que usam simulações podem ser aprovados em ambientes de área de trabalho, mas falhar na nuvem.
-
Estruturas simuladas, como emuladores, são limitadas em testar ou detectar AWS Identity and Access Management (IAM) políticas ou limitações de cotas.
-
Embora as simulações sejam melhores para simular o que uma aplicação fará quando a autorização falhar ou uma cota for excedida, os testes de simulação não podem determinar qual será realmente o resultado quando o código for implantado em um ambiente de produção.
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 em relação aos valores mais recentes APIs e de retorno.
-
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 poderão ser menos viáveis se você não tiver acesso à Internet de alta velocidade.
-
Os testes na nuvem normalmente exigem ambientes de nuvem isolados uns dos outros. 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.
Teste de emulação
O teste de emulação é ativado por aplicativos executados localmente, conhecidos como emuladores, que se assemelham AWS a serviços. 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 PutObjectmé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 uma aplicação de n camadas, talvez tenha um mecanismo de banco de dados e um servidor Web, semelhantes aos executados em produção na sua máquina local para fornecer uma capacidade de teste rápida, local e isolada.
-
Ele não exige qualquer alteração na infraestrutura de nuvem (como contas de desenvolvedores na nuvem). Por isso, é fácil 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 pipelines de CI/CD. 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 aquém das 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 AWS serviços 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.