Desafios ao testar aplicações com tecnologia sem servidor

Ao usar emuladores e chamadas simuladas para testar a aplicação com tecnologia sem servidor no desktop local, é possível observar inconsistências de teste à medida que seu código progride de ambiente para ambiente em seu pipeline de CI/CD. Os testes unitários que você criar em seu desktop para validar a lógica de negócios da aplicação podem não incluir ou representar com precisão aspectos críticos dos serviços em nuvem. Não é possível realizar testes completos 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.

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

Se a lógica de uma função do Lambda depender da criação de um bucket do S3, um teste completo deverá confirmar que o Amazon S3 foi chamado com êxito 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 CreateBucketAPI 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. Geralmente, essa é 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 capturar se a função do Lambda é capaz de criar o bucket de forma bem-sucedida, considerando 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 o perfil atribuído à função não tem uma política associada que permita a ação s3:CreateBucket. Consequentemente, a função sempre falhará quando implantada em um ambiente de nuvem.

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

Se uma fila do Amazon SQS for a origem de uma função do Lambda, um teste completo deverá verificar se a função do Lambda vai ser invocada com êxito quando uma mensagem for colocada em uma fila. Os testes de emulação e simulação geralmente são configurados para executar o código da função do Lambda diretamente e para simular a integração do Amazon SQS passando uma carga útil de eventos JSON (ou um objeto desserializado) como entrada do manipulador da função.

O teste local que simula a integração do Amazon SQS testará o que a função do Lambda fará quando for chamada pelo Amazon SQS com uma determinada carga útil, mas o teste não garantirá que o Amazon SQS invocará com êxito a função do 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.

• O perfil de execução da função do Lambda não permite a leitura de mensagens da fila (via sqs:ReceiveMessage, sqs: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.