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á.
# Práticas recomendadas para testar aplicações com tecnologia sem servidor
As seções a seguir descrevem práticas recomendadas para obtenção de uma cobertura eficaz ao testar aplicações com tecnologia sem servidor.
## Priorize os testes na nuvem
Para aplicações bem projetadas, é possível empregar toda uma variedade de técnicas de teste para satisfazer diversos requisitos e condições. No entanto, com base nas ferramentas atuais, recomendamos se concentrar nos testes na nuvem o máximo possível. Embora os testes na nuvem possam criar latência para o desenvolvedor, aumentar os custos e, às vezes, exigir investimentos em DevOps controles adicionais, essa técnica fornece a cobertura de teste mais confiável, precisa e completa.
Recomenda-se ter acesso a ambientes isolados para realizar testes. O ideal é que cada desenvolvedor tenha um espaço dedicado Conta da AWS para evitar problemas com a nomenclatura de recursos que possam ocorrer quando vários desenvolvedores que estão trabalhando no mesmo código tentam implantar ou invocar chamadas de API em recursos com nomes idênticos. Esses ambientes devem ser configurados com alertas e controles para evitar gastos desnecessários. Por exemplo, você pode limitar o tipo, a camada ou o tamanho dos recursos que podem ser criados e configurar alertas por e-mail quando os custos estimados excederem um determinado limite.
Se você precisar compartilhar um single Conta da AWS com outros desenvolvedores, os processos de teste automatizados devem nomear os recursos de forma que sejam exclusivos para cada desenvolvedor. Por exemplo, scripts de atualização ou arquivos de configuração TOML que causam comandos AWS SAM [CLI sam deploy [ou sam](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-sync.html)](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-deploy.html) sync podem especificar automaticamente um nome de pilha que inclua o nome de usuário do desenvolvedor local.
O teste na nuvem é valioso para todas as fases do teste, incluindo testes unitários, testes de integração e end-to-end testes.
## Use simulações, se necessário
As estruturas simuladas são uma ferramenta valiosa para escrever testes unitários rápidos. Elas são especialmente valiosas quando os testes abrangem lógicas de negócios internas complexas, como cálculos ou simulações matemáticas ou financeiras. Procure testes unitários que tenham um grande número de casos de teste ou variações de entrada nos quais essas entradas não alterem o padrão ou o conteúdo das chamadas para outros serviços de nuvem. A criação de testes simulados para esses cenários pode melhorar os tempos de iteração do desenvolvedor.
O código coberto por testes unitários com simulações também deve ser abordado por testes na nuvem. Isso é necessário porque as simulações ainda estão sendo executadas no laptop ou na máquina de compilação do desenvolvedor, e o ambiente pode ser configurado de forma diferente do que na nuvem. Por exemplo, seu código pode incluir AWS Lambda funções que usam mais memória ou demoram mais do que o Lambda está configurado para alocar quando executado com determinados parâmetros de entrada. Ou seu código pode incluir variáveis de ambiente que não estão configuradas da mesma forma (ou de forma alguma), e as diferenças podem fazer com que o código se comporte de forma diferente ou falhe.
Não use simulações de serviços em nuvem para validar a implementação adequada dessas integrações de serviços. Embora seja aceitável simular um serviço de nuvem ao testar outras funcionalidades, você deve testar as chamadas de serviço de nuvem na nuvem para validar a configuração correta e a implementação funcional.
As simulações podem agregar valor aos testes unitários, especialmente quando você testa um grande número de casos com frequência. Esse benefício é reduzido para testes de integração, porque o nível de esforço para implementar as simulações necessárias aumenta com o número de pontos de conexão. End-to-endos testes não devem usar simulações, porque esses testes geralmente lidam com estados e lógica complexa que não podem ser facilmente simulados com estruturas simuladas.
## Entenda as vantagens e desvantagens dos testes de emulação
Os emuladores podem ser uma opção prática para casos de uso específicos. Por exemplo, uma equipe de desenvolvimento com acesso limitado, inconsistente ou lento à Internet pode descobrir que o teste de emulação é a maneira mais confiável de iterar o código antes de migrar para um ambiente de nuvem.
Para a maioria das outras circunstâncias, use emuladores seletivamente. Quando você depende muito de um emulador, pode ser difícil incorporar novos recursos de AWS serviço em seus testes até que o fornecedor da emulação lance uma atualização para fornecer paridade de recursos. Os emuladores também exigem investimento inicial e contínuo para instalação e configuração em sistemas de desenvolvimento e máquinas de construção. Além disso, muitos serviços em nuvem não têm emuladores disponíveis; selecionar uma estratégia que priorize a emulação pode impedir o uso desses serviços ou produzir códigos e configurações que não são bem testados em relação ao comportamento real do serviço.
Se você usa testes de emulação, complemente-os com testes em nuvem o máximo possível para validar se as configurações de nuvem adequadas estão em vigor e para testar interações com serviços que só podem ser simulados ou simulados em um ambiente emulado.
O teste de emulação pode fornecer feedback rápido para testes unitários e, dependendo dos recursos e da paridade comportamental do software de emulação, também pode oferecer suporte a algumas integrações e end-to-end testes.
## Testes de escopo através de limites naturais
À medida que os aplicativos sem servidor crescem em mais componentes arquitetônicos, surgem limites naturais em torno dos subsistemas, especialmente ao seguir as melhores práticas, como funções de propósito único e desacoplamento orientado por eventos. Esses limites servem como bordas de teste eficazes, nas quais você pode validar contratos entre componentes.
### Identifique os limites da arquitetura
Procure costuras naturais no design do seu aplicativo:
+ Entre serviços, como uma EventBridge regra da Amazon conectando um editor a um consumidor
+ Nas bordas da API, como endpoints do Amazon API Gateway que oferecem funções do Lambda
+ Em torno de fluxos de trabalho, como AWS Step Functions orquestrar vários serviços
+ Em camadas de armazenamento, como o Amazon DynamoDB, streams que acionam o processamento downstream
### Separe o código Lambda da lógica de negócios
Simplifique seus testes isolando o código Lambda da lógica de negócios principal. Seu manipulador Lambda deve atuar como um adaptador fino entre o AWS tempo de execução e a lógica do seu aplicativo. Ele deve extrair e validar os dados do evento e, em seguida, delegar a uma função testável que não tenha dependências do Lambda. Isso torna sua lógica de negócios portátil, mais fácil de raciocinar e fácil de testar, sem simular objetos Lambda ou configurar ambientes complexos.
### Trate os limites como contratos
Teste no limite, não através dele. Valide o que ultrapassa o limite sem exigir todo o sistema a jusante. Esses mesmos limites também servem como ganchos de observabilidade na produção. As costuras arquitetônicas nas quais você testa podem ser instrumentadas para monitoramento usando Amazon CloudWatch Logs, AWS X-Ray traces e EventBridge eventos.
## Use equipamentos de teste para fluxos de trabalho assíncronos
Os aplicativos sem servidor geralmente dependem de padrões assíncronos, em que os eventos acionam o processamento, as mensagens fluem pelas filas e os fluxos de trabalho abrangem vários serviços sem respostas imediatas. Você não pode simplesmente invocar uma função e inspecionar um valor de retorno. O resultado pode aparecer posteriormente em um banco de dados, em um fluxo de log ou em outro serviço.
Um equipamento *de teste é testar a* infraestrutura que você implanta junto com seu aplicativo para observar e validar esse comportamento assíncrono. Os arneses de teste geralmente incluem:
+ Ouvintes de eventos que se inscrevem nos mesmos eventos que seu aplicativo produz
+ Mecanismos de armazenamento (como tabelas do DynamoDB ou buckets do Amazon S3) em que os resultados dos testes podem ser capturados
+ Lógica de pesquisa em seu código de teste que espera que os resultados esperados apareçam
Seu código de teste inicia um evento, aguarda a conclusão do fluxo de trabalho e, em seguida, consulta o equipamento de teste para verificar se o resultado esperado ocorreu.
Veja a seguir as práticas recomendadas:
+ **Defina claramente SLAs para operações assíncronas** — Estabeleça quanto tempo os fluxos de trabalho devem durar e use-os como tempos limite de pesquisa em seus testes
+ **Use identificadores exclusivos para isolamento de teste** — gere nomes de arquivos IDs, mensagens ou tokens de correlação exclusivos por execução de teste para evitar interferência entre os testes
+ **Implante a infraestrutura de teste junto com seu aplicativo** — inclua recursos de teste em seus infrastructure-as-code modelos para que eles permaneçam sincronizados à medida que seu aplicativo evolui
+ **Limpe os dados de teste após a execução do teste** — Isso evita o acúmulo de artefatos de teste em seu ambiente de nuvem
Os equipamentos de teste são mais valiosos para testes de integração que validam fluxos de trabalho em vários serviços, end-to-end testes que verificam jornadas completas do usuário e arquiteturas orientadas por eventos em que os serviços se comunicam por meio do EventBridge Amazon SNS, Amazon SQS ou Amazon Kinesis.
## Organize ambientes de nuvem para isolamento de desenvolvedores
Os testes na nuvem exigem ambientes isolados uns dos outros. Quando os desenvolvedores compartilham uma única conta Conta da AWS, como uma conta de desenvolvimento em equipe, considere criar uma pilha de aplicativos separada para cada desenvolvedor ou ramo de recursos. Isso isola recursos, evita colisões de nomes e evita contenção de cotas ou problemas ruidosos com vizinhos durante o teste.
Use o AWS Systems Manager Parameter Store ou ferramentas similares para gerenciar configurações específicas da pilha, como endpoints de API e nomes de filas. Para obter eficiência de custos, compartilhe recursos caros, como clusters do Amazon Relational Database Service (Amazon RDS), entre pilhas de desenvolvedores, mantendo recursos leves sem servidor (como funções Lambda, estágios do API Gateway e tabelas do DynamoDB) isolados por pilha.
Em setores regulamentados, as políticas de segurança corporativa podem restringir o acesso do desenvolvedor aos ambientes de nuvem, dificultando a execução de testes de nuvem como parte de um fluxo de trabalho de desenvolvimento local. Nesses casos, o teste de emulação pode preencher a lacuna entre o teste simulado local e a validação completa da nuvem, embora deva ser complementado com testes em nuvem sempre que o acesso permitir.
## Acelere os ciclos de feedback
Ao testar na nuvem, use ferramentas e técnicas para acelerar os ciclos de feedback do desenvolvimento. Por exemplo, use o modo [AWS SAM Acelerar](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/accelerate.html) e AWS CDK observar para diminuir o tempo necessário para enviar modificações de código para um ambiente de nuvem. As amostras no [repositório GitHub Serverless Test Samples](https://github.com/aws-samples/serverless-test-samples) exploram algumas dessas técnicas.
Também recomendamos que você crie e teste recursos de nuvem a partir de sua máquina local o mais cedo possível durante o desenvolvimento, e não somente depois de verificar o controle de origem. Essa prática permite uma exploração e experimentação mais rápidas no desenvolvimento de soluções. Além disso, a capacidade de automatizar a implantação em uma máquina de desenvolvimento ajuda a descobrir problemas de configuração da nuvem com mais rapidez e reduz o esforço desperdiçado em atualizações e aprovações de modificações no controle de versão.