Desafios ao testar aplicações com tecnologia sem servidor

Ao usar emuladores e chamadas simuladas para testar seu aplicativo sem servidor em seu desktop local, você pode experimentar inconsistências de teste à medida que seu código progride de um ambiente para outro em seu pipeline. CI/CD Os testes de unidade que você cria em seu desktop para validar a lógica de negócios do seu aplicativo podem não incluir ou representar com precisão aspectos críticos dos serviços em nuvem. Testes completos não podem ser realizados localmente de forma isolada. Eles exigem a verificação das permissões e configurações entre vários serviços.

As seções a seguir descrevem os desafios que podem surgir durante a implementação de uma estratégia de teste na nuvem. As seções a seguir descrevem os desafios que os clientes enfrentam ao tentar implementar uma estratégia de teste na nuvem e nossa orientação sobre as melhores práticas para obter uma cobertura de teste eficaz.

Exemplo: uma função Lambda que cria um bucket do Amazon S3

Se a lógica de uma função Lambda depender da criação de um bucket do Amazon S3, um teste completo deverá confirmar que o Amazon S3 foi chamado com sucesso e que o bucket foi criado com sucesso. Em uma configuração de teste de simulação, você pode simular uma resposta bem-sucedida e potencialmente adicionar um caso de teste para lidar com uma resposta de falha. Em um cenário de teste de emulação, a CreateBucket API pode ser chamada, mas a identidade que faz a chamada não se originará do serviço Lambda assumindo uma função e, em vez disso, uma autenticação de espaço reservado será usada ― essa geralmente é sua função ou identidade de usuário mais permissiva.

As configurações de simulação e emulação discutidas anteriormente provavelmente testarão o que a função do Lambda fará se chamar com sucesso (ou não) o Amazon S3. No entanto, esses testes não conseguirão detectar se a função Lambda é capaz de criar o bucket com sucesso, dada a configuração da função. Essa configuração provavelmente é representada pela infraestrutura como código (IaC) para produtos e serviços como AWS CloudFormation AWS SAM, ou HashiCorp Terraform. Um possível problema é que a função atribuída à função não tem uma política anexada que permita a s3:CreateBucket ação e, portanto, a função sempre falhará quando for implantada em um ambiente de nuvem.

Exemplo: uma função Lambda que processa mensagens do Amazon SQS

Se uma fila do Amazon Simple Queue Service (Amazon SQS) for a origem de uma função Lambda, um teste completo deverá verificar se a função Lambda foi invocada com sucesso quando uma mensagem for colocada em uma fila. O teste de emulação e o teste simulado geralmente são configurados para executar o código da função Lambda diretamente e para simular a integração com o Amazon SQS passando uma carga de evento JSON (ou um objeto desserializado) como entrada do manipulador da função.

Testes locais que simulam a integração do Amazon SQS testarão o que a função Lambda fará quando for chamada pelo Amazon SQS com uma determinada carga, mas não garantirão que o Amazon SQS invoque com sucesso a função Lambda quando ela for implantada em um ambiente de nuvem.

Alguns exemplos de problemas de configuração que você pode encontrar com o Amazon SQS e o Lambda incluem o seguinte:

• O tempo limite de visibilidade do Amazon SQS é muito baixo, resultando em várias invocações quando apenas uma foi planejada.

• A função de execução da função Lambda não permite a leitura de mensagens da fila (por meio de sqs:ReceiveMessagesqs:DeleteMessage, ou). sqs:GetQueueAttributes

• O evento de exemplo que é passado para a função do Lambda excede a cota de tamanho de mensagem do Amazon SQS. Portanto, o teste é inválido porque o Amazon SQS nunca seria capaz de enviar uma mensagem desse tamanho.

Como mostrado nesses exemplos, os testes que abrangem a lógica de negócios, mas não as configurações entre os serviços de nuvem, provavelmente fornecerão resultados não confiáveis.