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á.

Testando aplicativos sem servidor em AWS

Amazon Web Services (Colaboradorescolaboradores)

Março de 2026 (histórico do documento)

Este guia discute metodologias para testar aplicações com tecnologia sem servidor, descreve os desafios que você pode encontrar durante o teste e apresenta práticas recomendadas. Essas técnicas de teste têm como objetivo ajudar você a iterar com mais rapidez e lançar seu código com mais confiança.

Este guia destina-se a desenvolvedores que desejam estabelecer estratégias de teste para suas aplicações com tecnologia sem servidor. Você pode usar o guia como ponto de partida para aprender sobre estratégias de teste e, em seguida, visitar o Repositório de exemplos de teste com tecnologia sem servidor para ver exemplos de testes que seguem os padrões e as práticas recomendadas descritos neste guia. Este guia descreve metodologias de teste sem servidor, descreve os desafios que os clientes enfrentam ao testar aplicativos sem servidor e apresenta as melhores práticas para testar aplicativos sem servidor. Essas técnicas têm como objetivo ajudar os desenvolvedores a iterar com mais rapidez e lançar com mais confiança.

Visão geral do

Os testes automatizados são investimentos essenciais que ajudam a garantir a qualidade e a velocidade de desenvolvimento de aplicações. Os testes também aceleram o feedback dos desenvolvedores. Como desenvolvedor, você quer poder iterar rapidamente em sua aplicação e obter feedback sobre a qualidade do seu código. Muitos desenvolvedores estão acostumados a escrever aplicações que são implantadas em um ambiente de desktop, diretamente no sistema operacional ou em um ambiente baseado em contêiner. Ao trabalhar em ambientes de desktop ou baseados em contêineres, normalmente você escreve testes em código hospedado inteiramente em seu desktop. No entanto, em aplicações com tecnologia sem servidor, os componentes da arquitetura podem não ser implantáveis em um ambiente de desktop, mas podem existir somente na nuvem. Uma arquitetura baseada em nuvem pode incluir camadas de persistência, sistemas de mensagens, construções de segurança e outros componentes APIs. Quando você escreve um código de aplicação que depende desses componentes, pode ser difícil determinar a melhor maneira de projetar e executar testes.

Este guia ajuda você a se alinhar a uma estratégia de teste que reduz o atrito e a confusão e aumenta a qualidade do código.

Pré-requisitos

Este guia pressupõe que você esteja familiarizado com os conceitos básicos dos testes automatizados, incluindo como os testes automatizados de software são usados para garantir a qualidade do software. O guia fornece uma introdução de alto nível a uma estratégia de teste de aplicativos sem servidor e não exige nenhuma experiência prática em escrever testes.

Definições

Este guia usa os seguintes termos:

Objetivos

As práticas recomendadas deste guia têm como objetivo ajudar você a atingir dois objetivos principais:

Aumentar a qualidade do software

A qualidade de um aplicativo depende em grande parte da capacidade dos desenvolvedores de testar uma variedade de cenários para verificar a funcionalidade. Quando você não implementa testes automatizados ou, mais comumente, se seus testes não cobrem adequadamente os cenários necessários, a qualidade do seu aplicativo não pode ser determinada ou garantida.

Na arquitetura baseada em servidor, as equipes frequentemente definem um escopo para testes. Todo o código executado no servidor de aplicações deve ser testado. Outros componentes que chamam o servidor, ou dependências que o servidor chama, geralmente são considerados externos e fora do escopo dos testes pela equipe responsável pela aplicação no servidor.

As aplicações com tecnologia sem servidor geralmente consistem em unidades de trabalho menores, como funções do AWS Lambda , que são executadas em seu próprio ambiente. As equipes provavelmente serão responsáveis por muitas dessas pequenas unidades em uma única aplicação. Algumas funcionalidades da aplicação podem ser delegadas inteiramente para serviços gerenciados, como o Amazon Simple Storage Service (Amazon S3) ou o Amazon Simple Queue Service (Amazon SQS), sem o uso de nenhum código desenvolvido internamente. Os modelos tradicionais baseados em servidor para testes de software podem excluir serviços gerenciados ao considerá-los externos à aplicação. Isso pode levar a uma cobertura inadequada em que cenários críticos podem ser limitados a testes exploratórios manuais ou a alguns casos de teste de integração em que o resultado varia de acordo com o ambiente. Portanto, adotar estratégias de teste que englobam comportamentos de serviços gerenciados e configurações de nuvem pode melhorar a qualidade do software.

Teste nos limites da arquitetura

À medida que os aplicativos sem servidor crescem, eles naturalmente se espalham por vários componentes arquitetônicos. Embora isso use recursos AWS distribuídos, pode dificultar a compreensão do end-to-end comportamento.

Identificação de limites naturais

Ao projetar sua arquitetura seguindo as melhores práticas sem servidor (uma função = um trabalho, desacoplamento), você notará limites naturais em torno dos subsistemas. Esses limites representam pontos de separação lógica em seu aplicativo.

Limites como contratos de teste

Esses limites arquitetônicos são excelentes candidatos para testar bordas. Trate cada limite como um contrato e valide se ele se comporta de acordo com a especificação definida. Pense nesses limites como pontos em seu aplicativo onde você pode inserir a validação do teste.

Benefícios principais

A seguir estão os principais benefícios dos testes nos limites da arquitetura:

Teste nos limites do código

Defina limites claros de código separando o código de infraestrutura, como o código Lambda, da sua lógica comercial principal. Essa separação cria escopos de teste distintos que simplificam sua estratégia de teste.

O padrão de limite

Estabeleça dois limites de código claros em suas funções do Lambda:

Manipulador como adaptador (escopo externo)

Seu manipulador de funções Lambda deve ser uma camada fina que:

Lógica de negócios (escopo interno)

Sua lógica de negócios principal deve:

Testando benefícios por escopo

Essa abordagem baseada em limites permite que você teste a maior parte do seu código como funções puras, mantendo os testes do Lambda mínimos e direcionados.

Diminuir o tempo para implementar ou alterar recursos

Você pode minimizar o efeito de bugs de software e problemas de configuração nos custos e cronogramas detectando esses problemas durante um ciclo de desenvolvimento iterativo. Quando um desenvolvedor não consegue detectar esses problemas, mais pessoas precisam investir esforços adicionais para identificar os problemas.

Uma arquitetura com tecnologia sem servidor inclui serviços gerenciados que fornecem funcionalidade de aplicações  críticas por meio de chamadas de API. Por esse motivo, seu ciclo de desenvolvimento deve incluir testes que validem tanto o caminho feliz (em que as interações com esses serviços se comportam conforme o esperado) quanto o caminho triste (em que as chamadas falham, retornam respostas inesperadas ou se comportam de maneira diferente em todos os ambientes). Sem esses testes, você pode encontrar problemas decorrentes de diferenças entre o ambiente local e o ambiente implantado. Quando isso acontece, você deve passar mais tempo tentando reproduzir e verificar uma correção, porque agora cada iteração exige a validação das alterações em um ambiente diferente da sua configuração preferida.

Uma estratégia de teste com tecnologia sem servidor adequada melhora seu tempo de iteração fornecendo resultados precisos para testes que incluem chamadas para outros serviços.