BLOG

Por que o Threat Stack automatiza os testes de microsserviços usando contêineres

Miniatura F5
F5
Publicado em 18 de fevereiro de 2020

O Threat Stack agora é F5 Distributed Cloud App Infrastructure Protection (AIP). Comece a usar o Distributed Cloud AIP com sua equipe hoje mesmo .

Microsserviços, mesmo quando projetados corretamente, podem ser difíceis de testar. Mas quando a arquitetura do sistema evolui a ponto de dezenas ou centenas de serviços conectados comporem uma plataforma de software em uma infraestrutura em constante mudança, testar o produto pelo qual você e sua equipe são responsáveis se torna uma tarefa monumentalmente complexa. Escrever automação de testes para esses ambientes é difícil, então você quer garantir que obterá o máximo valor dos testes que escrever.

Na Threat Stack, escrevemos testes de integração de sistemas, uma forma de teste funcional de caixa cinza, e escolhemos o Docker para executar o ambiente de teste em contêiner.

O que há de errado com outros tipos de testes?

Algumas organizações ainda contam com o modelo de teste tradicional, no qual os testes de caixa branca e caixa preta são vistos como uma estratégia de teste complementar suficiente. Embora ainda desempenhem um papel importante na qualificação de software, eles não são mais suficientes para fornecer o feedback necessário para lançar software com confiança.

Nesse tipo de ambiente, os testes de aceitação do usuário de caixa preta são muito focados e confiar neles pode ter implicações sérias nas estratégias de tempo de colocação no mercado:

  • Ele não fornece cobertura adequada, pois há muitos cenários possíveis para testar no tempo alocado para a execução dos testes.
  • Ele é executado por longos períodos de tempo e pode frequentemente expirar devido a fatores além do controle do seu aplicativo.
  • Ele deve ser executado após a implantação do serviço, em vez de no momento da compilação, o que significa que o feedback fica ainda mais separado do desenvolvimento do produto. Na filosofia shift-left que domina a engenharia de testes, confiar nesses testes torna sua organização menos competitiva.
  • Como são testes de caixa preta, determinar a causa das falhas pode ser uma tarefa incrivelmente difícil.
  • Eles não são facilmente escritos ou mantidos pelos desenvolvedores.

Por outro lado, os testes unitários de caixa branca têm um foco muito restrito e são frequentemente usados incorretamente para qualificar a funcionalidade do sistema de software:

  • Ele não leva em consideração o comportamento real dos serviços que interagem com componentes ou outros serviços.
  • Ele pode testar cenários sem sentido que não são valiosos o suficiente para serem mantidos.
  • Isso pode se tornar oneroso para desenvolvedores que precisam atualizar continuamente grandes coleções de testes para pequenas alterações no código.
  • Não é facilmente escrito ou mantido por engenheiros de teste.

Por que focar em testes de integração de sistemas?

Os engenheiros de teste do Threat Stack dependem cada vez mais de testes de integração de sistemas para testar todos esses serviços de uma forma que maximize a cobertura do teste e, ao mesmo tempo, forneça a velocidade e a especificidade necessárias para garantir que o aplicativo se comportará corretamente sob muitas condições operacionais.

Um teste de integração é um teste de caixa cinza que se concentra no comportamento do software ou sistema em teste ao interagir com componentes externos. Por exemplo:

  • Um armazenamento de dados, por exemplo, PostgreSQL, Cassandra, ElasticSearch
  • Um corretor de mensagens, por exemplo, Kafka
  • Um servidor HTTP

Em outras palavras, software com o qual você pode interagir para validar comportamento. Na Threat Stack, executamos principalmente testes funcionais que replicam situações reais, mas os comportamentos testados param nos limites do ambiente em contêiner, evitando interações externas indesejadas.

E como esses testes são fortemente acoplados ao microsserviço, você tem o benefício de examinar e integrar o código do serviço em teste nos testes automatizados para identificar consistentemente áreas do código a serem exercitadas. Além disso, esses testes podem ser escritos como testes de aceitação do usuário para que pessoas não desenvolvedoras, como gerentes de produto e engenheiros de controle de qualidade, possam entender mais facilmente o comportamento sob teste.

Em outras palavras:

Dado um conjunto de algumas condições

Quando o serviço recebe esta entrada (OU esta condição afeta o serviço)

Então o serviço se comporta de maneira esperada e produz efeitos colaterais esperados

Esses testes funcionais não são apenas fáceis de entender e escrever, mas também são fortemente acoplados ao código do microsserviço, de modo que podem ser facilmente executados e atualizados pelos desenvolvedores durante o processo de desenvolvimento ou posteriormente por engenheiros de teste dedicados.

Por que usar contêineres?

Os contêineres são extremamente úteis para sistemas de teste, pois permitem que você reproduza rapidamente seu ambiente de teste com recursos mínimos durante a duração dos testes e, em seguida, limpe-o facilmente quando os testes terminarem de ser executados. Ao contrário de muitos testes de automação de caixa preta, você não precisa de um ambiente de teste caro e sempre ativo para realizar seus testes de integração. Ao executar os testes, o comportamento do microsserviço pode ser reproduzido no ambiente de teste. 

Depois de definir um ambiente em contêiner que espelhe o ambiente do microsserviço em produção, sua estrutura de teste se torna os clientes externos ou serviços simulados que fazem interface com os componentes ou microsserviços em teste. Isso garante que o código de teste oriente todos os aspectos dos testes, o que permite que você controle muitos outros aspectos dos testes.

Para começar, o Docker é uma boa plataforma para criar rapidamente um ambiente em contêiner. Usando o Docker Compose , você pode definir e executar facilmente as seções do seu aplicativo em teste, localmente ou em CI, usando o mesmo código. Outras ferramentas e serviços de infraestrutura de contêiner, como Kubernetes , AWS EKS ou AWS Fargate , também podem ser usados para implantar seu ambiente de teste se sua organização oferecer suporte ao uso deles.

Conclusão

Em última análise, a decisão de concentrar os esforços de teste em testes de integração em oposição a outros tipos de automação oferece dois grandes benefícios:

  • Seus testes de microsserviços são deslocados para a esquerda para que sejam executados antes da implantação, o que fornece um feedback mais rápido para o desenvolvimento iterativo.
  • Você ainda executa testes em serviços e componentes reais, o que significa que você está reduzindo lacunas na cobertura de testes, mas ainda executando testes funcionais.

 

 

O Threat Stack agora é F5 Distributed Cloud App Infrastructure Protection (AIP). Comece a usar o Distributed Cloud AIP com sua equipe hoje mesmo .