Os testes só podem ser rápidos ou bons?

Houve um tempo em que os testes de fumaça eram literais. Quando cada startup começou comprando seus próprios racks de hardware de servidor, o teste inicial de fumaça de uma nova configuração de hardware envolveu um técnico no armário do servidor para garantir que a fumaça não começasse a sair de nenhum dos componentes.

Naquela época, como agora, o processo de teste de software era um equilíbrio entre a complexidade do teste e a velocidade. As equipes de controle de qualidade que construíram com confiança conjuntos enormes de testes unitários, testes de integração e testes ponta a ponta terminaram com tempos de execução de testes em horas ou dias. Como tal, estes testes minuciosos tornaram-se cada vez mais raros. Os testes básicos que todo desenvolvedor executa enquanto escreve código são, por definição, limitados em escopo e seu tempo de execução é sempre rigidamente controlado, pois um conjunto de testes que leva muito tempo para ser executado após cada alteração de código danificará irreparavelmente o fluxo de trabalho do desenvolvedor.

Mas a escolha entre qualidade de teste e velocidade é falsa. É possível criar sistemas de testes rápidos e de alta qualidade.

Fases de teste e qualidade – a falsa dicotomia

As diversas fases do teste são algumas vezes descritas como uma pirâmide ou um triângulo: à medida que nos aproximamos da produção, os testes tornam-se mais completos e com feedback mais lento. A relação é algo como o diagrama abaixo:

Fonte: Signadot

Os ambientes inferiores, como testes de unidade de estação de trabalho local e testes de contrato, são executados como parte da integração contínua (CI) e oferecem feedback mais rápido, mas sacrificam a qualidade – eles não são uma boa réplica da produção. À medida que você vai para ambientes mais elevados, você obtém feedback de maior qualidade, mas a velocidade do feedback é bastante lenta.

Em grande parte, o lado direito desse fluxo faz sentido: logo antes de um lançamento de produção, deveríamos executar testes que demoram um pouco mais para serem concluídos, oferecem mais feedback e encontram (quase) todos os problemas ou possíveis degradações de desempenho. Coisas como testes de usuário sintéticos e testes de carga são lentos por definição. Não é possível executar testes como esses toda vez que você faz uma pequena alteração no código como desenvolvedor, antes mesmo de enviar uma solicitação pull.

No entanto, o que faz com que os testes executados na parte esquerda deste diagrama sejam de “baixa qualidade”? Por que os testes que executamos 10 vezes por dia deveriam oferecer apenas evidências parciais de que nosso código realmente funciona? Além disso, sinto que se você perguntar aos desenvolvedores se os testes em suas estações de trabalho locais são confiáveis, a experiência deles com tais testes será melhorada. pior nos últimos cinco anos. Por que os testes locais têm qualidade tão baixa?

Testando soluções em múltiplas escalas

Em um bate-papo recente do Lean Coffee para engenheiros de plataforma, mais de um gerente de engenharia descreveu uma situação em que muitos dos estágios intermediários dos testes não ocorriam mais. Aqui estão algumas citações dessa discussão (essas citações não foram obtidas por acordo com os organizadores):

“(Seria ótimo ter) testes contratados, mas seria extremamente caro manter esses testes em nosso cluster.” Lembre-se de que, à medida que os microsserviços proliferam, os testes de contrato ficam mais caros de implementar e difíceis de manter.

“No momento, os testes consistem em testes unitários, que são de responsabilidade de cada desenvolvedor, e então algo como testes sintéticos como o estágio final, logo antes de ir para o teste.”

Neste caso, a referência a “sintéticos” é uma versão altamente automatizada de testes ponta a ponta, onde um navegador ou usuário sintético faz uma solicitação completa em uma cópia altamente precisa do cluster de produção. A questão de como criamos um ambiente preciso para executar esses testes ponta a ponta nos leva a uma solução que muitos tentam com resultados pouco satisfatórios.

Uma solução que não é boa nem barata

A versão mais geral desta compensação entre qualidade e velocidade acrescenta o custo como um fator. Tradicionalmente, o “custo” dos testes estava envolvido no tempo gasto pelos engenheiros. No entanto, nossos ambientes modernos de microsserviços criaram uma solução que também consegue ser cara em termos de tempo e custos de infraestrutura: o ambiente de desenvolvedor duplicado.

Assim que o cluster de teste ficou muito grande e complexo para ser executado na estação de trabalho de um desenvolvedor, uma solução proposta foi criar uma cópia desse cluster para os desenvolvedores testarem. Como as alterações dos desenvolvedores nesse cluster frequentemente entravam em conflito, esse cluster seria replicado posteriormente para cada desenvolvedor que desejasse testar as alterações.

Esta abordagem tem várias desvantagens significativas:

• Executar vários ambientes o tempo todo, apenas para esperar que alguém precise deles para teste, acarretará custos significativos de infraestrutura.
• Esses múltiplos clusters inevitavelmente ficarão desatualizados em relação aos ambientes de preparação e produção, levando a testes de qualidade inferior.
• Você pode desligar esses clusters quando eles não estiverem em uso ou fazer com que eles atualizem suas dependências sempre antes de executarem testes.

Qualidade é importante em testes

Embora desejemos testes que sejam executados de forma rápida e eficiente, devo voltar a concentrar-nos, em primeiro lugar, na qualidade dos testes. A mudança na complexidade de nossas arquiteturas na última década levou a testes realizados por desenvolvedores que são significativamente menos precisos do que antes.

Conversando com um grupo de desenvolvedores no mês passado em um encontro, perguntei se eles já haviam enviado código para teste que eles não tinham ideia de que funcionaria. Mais da metade da sala respondeu dizendo “sim”. Isso é perturbador. Independentemente de como mudarmos nosso processo, ele deverá produzir informações de teste de maior qualidade. Ter dados de produção de alta qualidade fornecerá sinais de teste de alta qualidade e aumentará significativamente a eficácia dos testes.

A ascensão do serviço terceirizado e o desafio da qualidade dos testes

Um grande problema com qualquer solução que crie muitos ambientes para desenvolvedores ou outros testadores é o espectro dos serviços de terceiros. Todos esses ambientes de teste atomizados não podem fornecer nenhum tipo de versão de teste precisa de um serviço de terceiros. Embora um serviço como o Stripe tenha uma maneira de simular transações para teste, elas não são dimensionadas para muitos clientes de “teste”. Os serviços de terceiros são outro motivo pelo qual queremos estabelecer ambientes de alta qualidade compartilhados entre engenheiros.

Multilocação em ambientes de teste

Em vez de continuar esperando grandes fases intermediárias de testes, como testes de contrato, equipes como Uber e DoorDash implementaram ambientes de testes compartilhados onde os desenvolvedores podem executar verdadeira integração e testes ponta a ponta no início de seu ciclo de desenvolvimento.

Multilocação é um Ideia poderosa com muitos exemplos

Vários sistemas, incluindo CPUs, sistemas operacionais e aplicativos, progridem em direção à multilocação para fazer uso mais eficiente do hardware e da infraestrutura. As CPUs usam multithreading para usar com mais eficiência outros sistemas disponíveis para o processador central. No mundo das operações, as máquinas virtuais são uma solução multilocatária além do hardware de computação física, e até mesmo os aplicativos suportam threads de execução simultâneos, outra forma de multilocação. No mundo da arquitetura em nuvem, é raro que qualquer sistema de computação realmente use espaços de hardware dedicados para locatários. Para escalabilidade contínua e eficiência de escala, a multilocação é padrão.

Um ambiente de teste compartilhado altamente preciso e multilocatário

Para compartilhar um cluster de teste ou pré-produção com uma grande equipe de desenvolvimento, é necessário trabalho adicional com uma ferramenta como Signadot para garantir que os testes e experimentos dos desenvolvedores não colidam entre si. Às vezes chamado de “sandboxes”, um sistema de isolamento de solicitações pode garantir que apenas as solicitações corretas sejam passadas para os serviços que executam um teste.

Saiba mais com Signadot

Na Signadot, buscamos melhores maneiras de realizar testes em um ambiente compartilhado e multilocatário. Temos alguns estudos de caso de usuários corporativos como Brex e artigos que estudam como equipes empresariais como Uber e Eventbrite resolvem o desafio de ambientes de testes compartilhados de alta qualidade.

A postagem Os testes só podem ser rápidos ou bons? apareceu primeiro em The New Stack.