O teste do back-end de um aplicativo da Web é uma parte essencial do processo de desenvolvimento e de qualquer monitoramento contínuo. Além disso, consulte os testes de front-end.
Desenvolvimento voltado a testes
No Desenvolvimento voltado a testes (TDD, na sigla em inglês), os requisitos do aplicativo são convertidos em casos de teste antes que um aplicativo seja totalmente implementado. Durante o desenvolvimento, esses testes são criados primeiro e implementados sucessivamente à medida que o aplicativo é criado. Requisitos claros (ou seja, casos de teste) garantem que o código final seja bem estruturado, atenda a todos os requisitos e esteja correto, o que é especialmente importante durante os estágios iniciais de desenvolvimento.
Integração contínua e testes automatizados
O teste de integração contínua (CI) executa automaticamente os testes em relação a qualquer mudança de código, como durante revisões de código ou quando ele é mesclado ao repositório de código. Os testes automatizados melhoram a qualidade geral e a confiança no código enviado reduzindo os riscos de falhas ou regressões durante o desenvolvimento. É recomendável configurar um sistema de teste automatizado no ambiente para garantir a integridade do aplicativo. Use um sistema compatível com sua arquitetura, plataforma e linguagem e que se integra perfeitamente ao pipeline de desenvolvimento. Por exemplo, use as ações do GitHub para um fluxo de trabalho de CI ou um pipeline de CI personalizado integrado à nuvem e personalizado para sua configuração.
Saiba mais sobre os princípios por trás dos testes automatizados e como melhorar seus testes. Saiba mais sobre testes de integração contínua e as práticas recomendadas para implementar, configurar e avaliar o sucesso.
Na próxima etapa, considere um pipeline automatizado de entrega contínua (CD) para implantar automaticamente alterações e atualizações no aplicativo.
Teste de unidade
O teste de unidade refere-se a testar partes pequenas e independentes do código de forma isolada. Use um framework de teste de unidade recomendado e conhecido para sua linguagem ou framework de back-end. Por exemplo, para um aplicativo monolítico baseado em Java, use JUnit. Para um aplicativo sem servidor baseado em JavaScript (incluindo Dart ou TypeScript), use um framework criado para testes JavaScript, como o Jest.
A maioria dos frameworks de back-end modernos tem recursos dedicados para testes. Integre esses recursos ao seu pipeline de CI para automatizar os testes. Confira se os testes de unidade oferecem uma boa cobertura de código do aplicativo. A maioria dos frameworks de teste oferece recursos para analisar e relatar sua cobertura de teste e permite a integração com seu pipeline de build.
Teste de integração
O teste de integração se refere a testar módulos ou partes maiores do aplicativo em conjunto. Em comparação com o teste de unidade, que se concentra em partes individuais do código, o teste de integração se concentra na integração de partes individuais da arquitetura. Isso também pode incluir fluxos completos que abrangem várias etapas e módulos em todo o aplicativo.
Os testes de integração podem abranger diferentes módulos do aplicativo que podem exigir interação com serviços externos, como armazenamento de dados, sistemas de arquivos ou pagamentos. Considere estruturar seu aplicativo para oferecer suporte a abstrações para esses serviços por meio da injeção de dependência ou de recursos semelhantes fornecidos pelo framework de back-end.
Teste de comportamento e funcionalidade
Ao abordar o back-end (ou módulos ou componentes individuais) como uma caixa opaca, os testes funcionais se concentram na entrada e na saída do sistema. Embora os testes comportamentais possam ser mais comuns para o front-end, eles também desempenham um papel fundamental na confirmação da integridade de ponta a ponta de um sistema de back-end. Esses tipos de teste confirmam que o sistema reage e se comporta como esperado em diferentes entradas.
Teste de regressão
Os testes de regressão se referem a testes que confirmam que o aplicativo ainda se comporta conforme o esperado. Os testes concluídos anteriormente são executados novamente para garantir que as alterações não tenham reintroduzido problemas anteriores. À medida que bugs são corrigidos em um aplicativo, testes de unidade ou integração precisam ser adicionados para garantir que o bug não recorrente. Os testes de regressão precisam ser integrados aos testes comuns e ao pipeline de compilação.
Teste de fumaça
O teste de fumaça, também chamado de teste de verificação do build, se concentra na verificação das funções mais importantes do aplicativo de back-end. Estendendo além do teste de integração, que abstrai alguns recursos e dependências externas, o teste preliminar abrange os casos de uso críticos do aplicativo. O teste de fumaça pode servir como uma camada adicional de verificação antes que um aplicativo seja promovido para o ambiente de preparação para garantir um comportamento preciso. Os testes de fumaça podem consistir em testes de unidade automatizados ou testes funcionais manuais realizados por uma equipe de controle de qualidade.
Ambientes de produção e preparo
Um ambiente de preparação é uma cópia do seu ambiente de produção, colocado no sandbox para facilitar os testes. Uma implantação dedicada reduz o risco de problemas com o ambiente de produção e facilita a realização da garantia de qualidade. O ambiente de preparo permite testar um sistema próximo ao ambiente de produção ativo.
Ter uma cópia individual do ambiente de produção pode não ser viável devido a fatores como custo ou complexidade da arquitetura de back-end. Considere quais partes do back-end são as mais críticas e otimize-as para um ambiente de preparação.
Testar com dados usados na produção oferece um ótimo benefício para testar como o aplicativo se comporta com dados reais. Considere as implicações de privacidade e as necessidades de armazenamento de dados nesse ambiente de preparação e projete cuidadosamente os dados usados pelo sistema de back-end. O acesso a esse ambiente precisa ser rigorosamente controlado, especialmente se dados de produção forem usados.
Considere a escala do sistema e se um ambiente estático é adequado para o aplicativo. Os ambientes de preparo graduais que podem ser implantados automaticamente por um sistema de entrega contínua também oferecem outras oportunidades para testar builds diários ou semanais e oferecem mais análises antes do lançamento.
Outra abordagem é confiar mais em testes de integração contínua e sistemas automatizados, em vez de em um ambiente de preparo totalmente implantado. Considere o fluxo de trabalho, a integridade do sistema, a cobertura do código e os requisitos técnicos de sua equipe.