Testes End-to-End em Microserviços: Onde Mora o Problema?

O problema não está em utilizar testes end-to-end, mas sim acreditar que eles são a única estratégia para a qualidade em uma arquitetura de microserviços.

Os testes end-to-end têm sido amplamente adotados como uma estratégia crucial para garantir a qualidade em sistemas complexos, especialmente em arquiteturas de microserviços. A promessa de validar fluxos de negócio completos e identificar bugs antes que cheguem à produção atrai muitas empresas a investir pesado nessa abordagem. No entanto, à medida que esses sistemas crescem em complexidade e as interdependências entre os serviços se tornam mais intrincadas, os testes E2E começam a revelar suas limitações.

Neste post, vamos conversar sobre os problemas que surgem ao confiar exclusivamente nos testes E2E em ambientes de microserviços. Vamos discutir como a espera prolongada por feedback, a instabilidade dos testes, o alto custo de manutenção, e as dificuldades de depuração estão comprometendo a agilidade e a eficiência das equipes de desenvolvimento. Além disso, veremos como a desaceleração da entrega de valor, a baixa eficiência em capturar bugs e a persistência de erros em produção evidenciam a necessidade de repensar essa estratégia.

Se você já se perguntou por que sua pipeline de testes está desacelerando suas entregas ou por que ainda há bugs escapando para produção, este artigo é para você.

O Propósito Central do Desenvolvimento de Software

Quando discutimos qualidade na engenharia de software, muitas vezes limitamos nossa compreensão à ausência de bugs ou à conformidade com especificações técnicas. Contudo, essa visão negligência aspectos fundamentais que tornam um produto digital realmente valioso. A qualidade não se resume apenas à correção técnica, mas também envolve a capacidade do software de resolver problemas reais de forma eficaz, proporcionando uma experiência positiva ao usuário e atendendo às expectativas do negócio.

A palavra "qualidade" tem suas raízes no latim "qualitas," derivada de "qualis," que significa "de que tipo" ou "de que natureza". Originalmente, referia-se às propriedades ou características que definem a essência de algo. Com o tempo, o conceito de qualidade evoluiu para representar não apenas as propriedades intrínsecas de um produto, mas também sua capacidade de gerar valor e atender às expectativas.

Embora muitos produtos digitais possam ter o mesmo propósito final de solução — como resolver um problema específico para um grupo de usuários ou atender a uma necessidade de negócio — a qualidade de cada um pode variar significativamente. A qualidade de um produto digital não é determinada apenas por sua capacidade de cumprir o propósito final, mas também por como ele atinge esse objetivo. Produtos diferentes podem resolver o mesmo problema, mas a maneira como o fazem, a experiência que proporcionam ao usuário, a eficiência, a confiabilidade, e a estética, entre outros fatores, podem diferenciar um produto de outro.

Para uma pequena parte (acredito eu) de engenheiros de software, analistas de negócios e até mesmo gerentes, a qualidade pode ser erroneamente vista como um obstáculo à agilidade. Isso ocorre porque o processo de garantir a qualidade é, por sua natureza, rigoroso e detalhista. Envolve não apenas testes e validações, mas também revisões constantes, ajustes e, por vezes, retrabalho. Esse processo pode parecer, em um primeiro momento, como algo que atrasa o desenvolvimento e a entrega de novas funcionalidades.

Mas essa visão ignora um ponto crucial: qualidade não é apenas sobre testar para encontrar falhas; é sobre garantir que o produto entregue realmente atenda às expectativas e necessidades dos usuários e do negócio. Um sistema que é lançado rapidamente, mas que falha em cumprir sua promessa, não está entregando valor – e o custo de corrigir essas falhas após o lançamento é significativamente maior do que o tempo investido para evitá-las durante o desenvolvimento.

Pense em um carro. Quando uma montadora lança um novo modelo, o veículo passa por uma série de testes rigorosos antes de chegar ao mercado – testes de colisão, testes de segurança, testes de desempenho em diferentes condições. Esses testes não são realizados para atrasar o lançamento do carro, mas sim para garantir que, uma vez nas mãos do consumidor, o carro seja seguro, confiável e capaz de atender às expectativas de seus futuros proprietários.

No entanto, quando uma fabricante falha em garantir a qualidade antes do lançamento, as consequências podem ser severas. Um problema identificado após o carro já estar em circulação geralmente resulta em um recall – um processo complicado que envolve localizar todos os veículos afetados, realizar reparos ou substituições, e gerenciar a insatisfação dos clientes. Os passos típicos de um recall incluem:

1. Identificação do Problema: Detectar o defeito que afeta a segurança ou funcionalidade do veículo.

2. Comunicação com os Proprietários: Informar os proprietários sobre o problema e as etapas necessárias para corrigi-lo.

3. Execução dos Reparos: Organizar os reparos ou substituições, que podem envolver a logística de trazer os carros para concessionárias ou oficinas autorizadas.

4. Gestão de Custos: Absorver os custos de reparo, logística, e possivelmente compensações para os consumidores.

5. Restabelecimento da Confiança: Trabalhar para recuperar a confiança dos consumidores que foram afetados, o que pode incluir lidar com a insatisfação e o receio de que o veículo possa ter outros problemas.

Para os proprietários dos veículos envolvidos em um recall, o processo pode gerar um misto de frustração e preocupação. Além do inconveniente de ter que levar o carro para reparo, há o receio de que outros problemas possam surgir, e a confiança na marca pode ser abalada. Para a montadora, o recall não é apenas um grande gasto financeiro, mas também um golpe na reputação.

Da mesma forma, na engenharia de software, os testes são uma parte essencial do processo de garantir que o produto final seja sólido, confiável e valioso. E se falharmos em garantir essa qualidade antes do lançamento, as consequências – como bugs em produção, falhas de segurança, e perda de confiança dos usuários – podem ser equivalentes ao impacto de um recall na indústria automotiva.

James Bach, engenheiro de software e especialista em testes, define testes de software como "um processo de questionamento do produto para avaliar sua qualidade". Em outras palavras, os testes são a ferramenta que usamos para desafiar o software, colocando-o à prova em diferentes situações, para garantir que ele possa lidar com os desafios do mundo real.

Quando uma nova funcionalidade é desenvolvida, ela deve passar por seus próprios "testes de colisão". Devemos testá-la não apenas em condições ideais, mas também em situações adversas – alta carga de usuários, falhas de rede, integração com outros sistemas – para garantir que ela seja robusta o suficiente para suportar esses desafios. Esses testes devem ser vistos não como um atraso, mas como um investimento na qualidade do produto e, por extensão, no sucesso do negócio.

O verdadeiro propósito dos testes em engenharia de software, então, é garantir que cada funcionalidade entregue esteja pronta para enfrentar o mundo real. Eles não existem para atrapalhar ou desacelerar o desenvolvimento, mas para assegurar que, quando uma funcionalidade chega ao usuário final, ela estará à altura das expectativas e será capaz de gerar o valor esperado. Quando entendemos os testes dessa forma, fica claro que eles são aliados, não inimigos, da agilidade e do sucesso do produto.

A Importância da Etapa de Discovery na Qualidade do Produto

Antes de qualquer linha de código ser escrita, existe uma fase crucial no desenvolvimento de software: a etapa de discovery. Durante essa fase, especialistas de negócio, donos do produto e engenheiros de software se reúnem para explorar e entender profundamente o problema que precisa ser resolvido. É aqui que o objetivo da solução é definido com clareza, e onde se determina como essa solução deve gerar valor real para o negócio e para os usuários.

Uma boa analogia para essa etapa é a construção de um edifício. Imagine uma equipe de engenheiros que está construindo um arranha-céu. Antes que qualquer tijolo seja assentado, é necessário um trabalho intenso de planejamento e engenharia para garantir que a fundação seja sólida o suficiente para suportar a estrutura. Se a fundação for mal projetada ou mal construída, todo o edifício estará em risco, independentemente de quão bem os andares superiores sejam construídos. Da mesma forma, no desenvolvimento de software, a etapa de discovery é como essa fundação: é onde se define claramente o que o edifício (ou software) deve ser e como ele deve funcionar.

Uma compreensão clara do problema e dos objetivos é essencial para que o produto final seja de alta qualidade. Sem uma sólida base de requisitos bem definidos e fundamentados em pesquisas e evidências, qualquer solução desenvolvida corre o risco de ser mal direcionada, não atendendo às necessidades reais do negócio ou dos usuários. A qualidade, portanto, começa muito antes da fase de testes; ela tem suas raízes na qualidade do pensamento e da análise durante a etapa de discovery.

Nesta fase, é vital que os engenheiros de software assumam um papel ativo, colaborando estreitamente com os especialistas de negócio e donos do produto. Eles trazem para a mesa a perspectiva técnica, ajudando a moldar a viabilidade das soluções propostas e garantindo que os requisitos sejam claros, realistas e implementáveis. Sem essa colaboração estreita, o risco de mal-entendidos e de expectativas desalinhadas aumenta significativamente, o que pode comprometer a qualidade do produto final.

Quando essa fase de discovery é bem conduzida, com todos os envolvidos entendendo profundamente o problema e os objetivos da solução, o desenvolvimento do software se baseia em uma fundação sólida. Isso, por sua vez, facilita a criação de um produto que não apenas cumpre sua função, mas o faz de maneira que agrega valor real e sustentável para o negócio e os usuários.

Portanto, antes de pensar em testes ou entregas ágeis, é crucial lembrar que a qualidade começa com uma discovery bem estruturada. Assim como um carro é exaustivamente testado para garantir sua segurança e desempenho, um software deve ser solidamente planejado e validado desde o início, assegurando que cada funcionalidade agregue valor de maneira eficiente e relevante para o negócio e para o usuário final.

E Onde os Testes de Ponta a Ponta Entram Nisso?

Com a fundação bem estabelecida na etapa de discovery, o desenvolvimento do software pode prosseguir com um senso claro de direção e propósito. Mas mesmo com todos os esforços para garantir que o planejamento seja sólido, ainda é necessário validar se a solução desenvolvida realmente cumpre o que foi proposto. É aqui que os testes de ponta a ponta, ou E2E, entram em cena.

Os testes E2E têm como objetivo verificar se todos os componentes de um sistema trabalham juntos como esperado, garantindo que os fluxos de negócio funcionem corretamente do início ao fim. Em um sistema de microserviços, esses testes podem ser essenciais para identificar problemas que surgem apenas quando todos os serviços estão operando em conjunto, simulando a experiência do usuário final.

No entanto, os testes de ponta a ponta, embora cruciais, não são isentos de desafios. Quando implementados de maneira inadequada ou excessiva, eles podem se tornar um gargalo significativo no processo de desenvolvimento e entrega de software. A necessidade de orquestrar múltiplos serviços e sistemas pode resultar em testes lentos, instáveis e difíceis de manter. Além disso, em arquiteturas complexas, o tempo necessário para obter feedback pode ser longo, o que, por sua vez, pode comprometer a agilidade das equipes.

Outro ponto crítico é que, enquanto os testes E2E são projetados para cobrir fluxos de negócio completos, eles podem falhar em apontar com precisão a causa de um problema. Quando um teste E2E falha, pode ser difícil identificar se o problema está em um serviço específico, na comunicação entre serviços, ou em alguma outra parte do sistema. Isso pode levar a um ciclo de depuração demorado e frustrante, que muitas vezes resulta em retrabalho e em uma desaceleração geral no processo de entrega.

Portanto, embora os testes E2E desempenhem um papel importante na validação de sistemas complexos, eles devem ser utilizados com discernimento. Sua implementação deve ser equilibrada com outras formas de teste, como testes de unidade e de integração, testes de contrato, que podem oferecer feedback mais rápido e isolado sobre componentes específicos do sistema. Combinados de maneira eficaz, esses diferentes tipos de testes podem proporcionar uma cobertura abrangente sem comprometer a agilidade. Vamos agora entrar em mais detalhes.

Entendendo os Pontos de Atenção nos Testes End-to-End

Os testes são a ferramenta que usamos para validar o comportamento observável do software, ou seja, se a solução que desenvolvemos realmente cumpre o que se propõe a fazer. Isso inclui testar se a funcionalidade atende aos requisitos de negócio, se oferece uma experiência de usuário satisfatória e se é tecnicamente sólida. Para garantir que o comportamento observável esteja correto, devemos dedicar tanta qualidade aos testes quanto dedicamos ao próprio software. Isso vale para todos os tipos de testes, sejam eles de unidade de código, aceitação, contrato ou end-to-end.

Cada estratégia de teste tem suas vantagens e desvantagens, e é essencial aplicá-las na dose certa. Os testes de unidade, por exemplo, oferecem feedback rápido e isolam problemas em componentes específicos, mas não capturam falhas de integração. Os testes de aceitação validam se o software atende às necessidades do negócio, mas podem não cobrir todas as nuances técnicas. Os testes de contrato asseguram que a comunicação entre serviços está correta, mas não garantem o comportamento completo do sistema. E os testes end-to-end, enquanto fundamentais para validar fluxos completos, podem se tornar armadilhas se usados de maneira inadequada.

Queremos evitar cair nessas armadilhas para não comprometer a agilidade na entrega de valor ao negócio. Por isso, é importante entender que, embora os testes end-to-end desempenhem um papel importante, eles não são a estratégia definitiva e devem ser utilizados com cautela.

Neste contexto, vamos focar em algumas armadilhas comuns que podemos enfrentar ao acreditar cegamente que os testes end-to-end são a solução final. Veremos oito pontos críticos que precisam de atenção especial:

1. Aguardo Prolongado por Feedback: À medida que a suite de testes end-to-end cresce, o tempo necessário para a execução completa dos testes também aumenta. Isso significa que os engenheiros precisam esperar mais tempo para receber feedback sobre as mudanças que fizeram, o que pode atrasar o desenvolvimento e reduzir a eficiência das equipes.

2. Falta de Confiança nos Resultados: Testes que falham de maneira inconsistente, também conhecidos como "flaky tests", são um grande desafio. Eles podem dar resultados diferentes para o mesmo código, o que leva à necessidade de reexecutar os testes para confirmar se houve realmente um problema. Isso gera uma falta de confiança na suite de testes e pode consumir tempo e recursos valiosos.

3. Alto Custo de Manutenção: Manter um ambiente de teste estável e consistente é uma tarefa difícil, especialmente em sistemas que requerem configurações manuais frequentes. Qualquer alteração manual pode corromper os dados de teste ou as condições do ambiente, tornando a manutenção dos testes cara e trabalhosa.

4. Dificuldade em Identificar a Causa das Falhas: Em ambientes onde a comunicação assíncrona é prevalente, a depuração de falhas nos testes pode se tornar extremamente complexa. Muitas vezes, é difícil conectar uma falha a sua causa real, como uma mensagem que não foi enviada para uma fila, resultando em comportamentos inesperados em outras partes do sistema. Isso complica o processo de encontrar e corrigir o problema.

5. Atraso na Entrega de Valor: Quando os commits de código são acumulados à espera de passar pela suite de testes end-to-end, o processo de implantação pode ser significativamente atrasado. Esse atraso na integração contínua pode reduzir a frequência das entregas, desacelerando a entrega de novas funcionalidades ou correções ao cliente.

6. Baixa Eficiência na Identificação de Bugs: Apesar de cobrir e interagir bastante com o sistema, os testes end-to-end nem sempre são eficazes em detectar comportamentos que não estão alinhados com as expectativas de negócio. Em alguns casos, mesmo após muitas execuções, o número de falhas detectadas pode ser desproporcionalmente baixo em comparação ao esforço e ao tempo investidos, o que levanta questões sobre a eficiência dessa abordagem.

Ao longo dos próximos tópicos, vamos explorar cada um desses pontos em profundidade, discutindo os cuidados que devemos ter em ambientes distribuídos, com integrações complexas, comunicação assíncrona constante, e uma grande variedade de regras de negócio.

A razão pela qual investimos tempo em testes não é apenas para garantir que o código funcione, mas para verificar se estamos alinhados com os propósitos de negócio e se o comportamento do software corresponde às expectativas tanto dos analistas de negócios quanto dos usuários finais.

Aguardo Prolongado por Feedback: O Impacto nos Times de Engenharia

À medida que as suites de testes end-to-end se expandem, o tempo necessário para a execução completa desses testes cresce exponencialmente. Esse aumento no tempo de execução não é apenas uma questão técnica; ele afeta profundamente a dinâmica de trabalho das equipes de engenharia, gerentes de produto (Product Managers), donos de produto (Product Owners), executivos e QA's. Para entender melhor o impacto, precisamos considerar o que está em jogo: tempo, valor e agilidade.

O Que Está Envolvido?

No desenvolvimento de software, feedback rápido é fundamental. Testes E2E são projetados para validar o comportamento do sistema como um todo, garantindo que todos os componentes interajam corretamente. No entanto, à medida que a complexidade do sistema aumenta, mais testes são adicionados à suite, o que naturalmente leva a um aumento no tempo de execução.

Chris Richardson, autor de Microservices Patterns, destaca que, em arquiteturas de microserviços, a necessidade de validar integrações entre serviços distintos pode gerar um número massivo de casos de teste. Cada novo serviço introduzido na arquitetura aumenta a necessidade de testes end-to-end para garantir que ele funcione corretamente com os outros serviços. Isso pode resultar em uma suite de testes E2E que, apesar de sua abrangência, se torna um gargalo, atrasando a implantação e minando um dos principais benefícios dos microserviços: a agilidade.

Richardson comenta que "os testes de ponta a ponta geralmente são um gargalo que reduz a frequência de implantação e anula o propósito de usar microserviços. Você tem um monólito - a unidade de implantação - que é composta de serviços. Ou, em outras palavras, um monólito distribuído." Essa visão crítica ressalta como o uso indevido ou excessivo de testes E2E pode transformar uma arquitetura que deveria ser ágil e modular em um monólito disfarçado.

Martin Fowler, um dos principais defensores do desenvolvimento ágil e testes contínuos, também aponta que "os testes são a âncora da qualidade, mas essa âncora pode se tornar um peso se não for gerida adequadamente." Quando os testes de ponta a ponta são mal dimensionados ou excessivamente dependentes, eles podem gerar exatamente o tipo de gargalo que Richardson menciona, criando um sistema onde a rapidez e a flexibilidade são sacrificadas.

Fowler vai além ao sugerir que uma abordagem desequilibrada em testes pode inflar o número de testes end to end a um ponto em que eles se tornam um fardo, em vez de um benefício. Ele afirma que, quanto mais alto na pirâmide de testes você sobe, menos testes deveria ter. Isso significa que os testes E2E, sendo de alto nível, devem ser usados com parcimônia¹.

Fowler alerta que um conjunto de testes E2E excessivo pode indicar fluxos de testes inflados, resultando em uma suite de testes que é lenta, frágil e cara de manter​.

Essa expansão contínua da suite de testes cria um ciclo onde o tempo de feedback se alonga, resultando em uma espera prolongada para os engenheiros que aguardam a confirmação de que suas mudanças não introduziram novos problemas. Esse atraso afeta diretamente o fluxo de trabalho da equipe e pode ter várias repercussões negativas.

O Desafio para os Engenheiros de Software

Para os engenheiros de software, o tempo é um recurso crucial. Quando uma mudança é implementada, o ideal é que eles recebam feedback quase que imediatamente. Isso permite que ajustes sejam feitos rapidamente, enquanto a mudança ainda está fresca na mente do desenvolvedor. No entanto, quando a suite de testes end-to-end demora horas para ser executada, esse feedback é retardado, forçando os engenheiros a mudarem o foco para outras tarefas enquanto aguardam os resultados. Esse contexto introduz uma série de desafios:

• Perda de Contexto: Quando o feedback é lento, os engenheiros podem perder o contexto da mudança feita. Isso significa que, se um problema for detectado, eles precisarão gastar tempo relembrando o que foi alterado e por que, o que diminui a eficiência.

• Multitarefa Ineficiente: Para contornar a espera, os engenheiros podem tentar trabalhar em outras tarefas enquanto aguardam o feedback, mas isso pode levar a uma multitarefa ineficiente. Frequentemente, trocar o foco entre tarefas complexas diminui a qualidade do trabalho e aumenta o risco de erros.

• Atraso na Correção de Bugs: Se uma falha é detectada após um longo tempo de espera, a correção imediata se torna difícil, resultando em mais tempo gasto para identificar e corrigir o problema, o que pode atrasar o desenvolvimento.

Impacto para Product Managers e Product Owners

Para Product Managers e Product Owners, a agilidade na entrega de novas funcionalidades e correções é fundamental para manter a competitividade e atender às demandas do mercado. Quando o feedback dos testes end-to-end é lento, o ciclo de desenvolvimento e implantação se prolonga. Isso pode ter várias consequências:

1. Diminuição da Agilidade: A capacidade de responder rapidamente a mudanças no mercado ou a novos insights dos usuários é reduzida. As funcionalidades demoram mais para chegar ao mercado, o que pode resultar em perda de oportunidades.

2. Planejamento Comprometido: Um ciclo de feedback prolongado torna mais difícil planejar as próximas etapas do desenvolvimento, já que as estimativas de tempo se tornam menos precisas. Isso pode afetar a comunicação com stakeholders e comprometer prazos.

3. Decisões Baseadas em Dados Desatualizados: O atraso no feedback pode significar que as decisões estão sendo tomadas com base em dados e situações que já mudaram, levando a escolhas menos informadas.

O Desafio para QA's e Executivos

Os QA's, responsáveis por garantir a qualidade final do produto, enfrentam desafios semelhantes. Quando o feedback é lento, eles têm menos tempo para identificar e relatar problemas antes que a próxima iteração comece. Isso pode levar a uma redução na eficácia dos testes e a um risco maior de problemas não detectados em produção.

Executivos, por sua vez, estão sempre atentos à eficiência e ao retorno sobre investimento (ROI). Um ciclo de feedback lento pode significar maiores custos de desenvolvimento e menor eficiência da equipe, o que, em última análise, impacta os resultados financeiros da empresa. Além disso, a lentidão no ciclo de desenvolvimento pode afetar a reputação da empresa no mercado, especialmente se a competição for mais ágil.

Perdendo Tempo, Valor e Agilidade

O tempo perdido esperando por feedback de testes end-to-end é tempo que poderia ser gasto criando novas funcionalidades, melhorando o produto ou corrigindo problemas. Isso reduz a agilidade do time de engenharia e diminui a capacidade da equipe de entregar valor rapidamente. O desenvolvimento ágil se baseia na premissa de ciclos curtos de feedback para permitir iterações rápidas e frequentes. Quando o feedback é atrasado, a capacidade de iterar rapidamente é comprometida, o que pode resultar em um produto menos competitivo e menos adaptado às necessidades do mercado.

Citando novamente o autor e consultor de software, Chris Richardson, ele nos faz um alerta :

“Testes end-to-end podem se tornar um gargalo significativo, especialmente onde a interdependência entre serviços aumenta a complexidade dos cenários e jornadas.”

Essa complexidade, se não for gerida com cuidado, pode transformar uma suite de testes projetada para garantir a qualidade em uma barreira que impede a agilidade e a entrega contínua de valor.

Richardson ainda destaca que muitas organizações recorrem a testes de ponta a ponta por descobrirem que os testes de nível de serviço não são suficientes para garantir a correção do aplicativo. No entanto, ele enfatiza que isso geralmente é um sintoma de uma arquitetura falha, onde os serviços não são projetados para serem implantáveis de forma independente, resultando na necessidade de uma suite E2E que, na prática, cria um "monólito distribuído". Ele sugere que, em vez de confiar cegamente nos testes E2E, a solução seria consertar a arquitetura, reduzindo o número de serviços e garantindo que cada serviço possa ser implantado de forma independente.

Martin Fowler, em seus escritos sobre integração contínua, também enfatiza a importância de "otimizar para feedback rápido". Ele argumenta que, sem um feedback rápido, a capacidade da equipe de reagir a problemas e iterar efetivamente é severamente limitada. Ele sugere o uso de uma pirâmide de testes, onde a maioria dos testes são unitários, rápidos e baratos, enquanto os testes E2E são minimizados para evitar esses gargalos.

O conceito de feedback rápido não é novo, mas sua importância não pode ser subestimada. Em um ambiente onde as decisões precisam ser tomadas rapidamente, e as mudanças precisam ser implementadas com agilidade, a lentidão nos testes end-to-end pode paralisar o processo de desenvolvimento. Quando o feedback é rápido, os engenheiros podem agir imediatamente, corrigir problemas, ajustar funcionalidades e continuar avançando. Isso mantém o fluxo de trabalho em movimento e permite que o produto evolua continuamente, mantendo-se relevante e competitivo.

A Visão de Sam Newman sobre Testes End-to-End

O consultor e escritor Sam Newman também discute extensivamente a importância dos ciclos de feedback nos testes. Ele argumenta que, em um ambiente de desenvolvimento ágil, onde a iteração rápida é essencial, o tempo de feedback dos testes deve ser o mais curto possível. Isso é crucial para permitir que os desenvolvedores identifiquem e corrijam problemas imediatamente, sem a necessidade de esperar por longos períodos para obter resultados dos testes.

Para Newman, ciclos de feedback longos, como os frequentemente associados aos testes E2E, podem ser prejudiciais ao processo de desenvolvimento. Quando os desenvolvedores precisam esperar muito tempo para saber se suas mudanças foram bem-sucedidas, isso afeta a produtividade e a moral da equipe. Além disso, ciclos de feedback prolongados podem resultar em uma maior quantidade de código sendo alterado antes que qualquer problema seja detectado, o que complica ainda mais a depuração e a correção de erros.

Newman advoga pelo uso de uma "pirâmide de testes", onde a base é composta por testes de unidade, que são rápidos e fornecem feedback quase instantâneo. Acima dos testes de unidade, ele coloca os testes de integração, que validam as interações entre componentes dentro de um serviço. No topo da pirâmide, estão os testes E2E, que são mais lentos e caros de executar, mas que ainda assim têm seu lugar para validar os fluxos críticos do sistema. Essa estrutura permite que a maior parte do feedback seja obtida rapidamente, mantendo a agilidade no desenvolvimento.

Sam Newman, em seu livro Building Microservices, oferece uma visão crítica e pragmática sobre o uso de testes end-to-end em arquiteturas de microserviços. Ele reconhece que, embora os testes E2E tenham seu valor, eles devem ser aplicados com cautela devido aos desafios que apresentam, especialmente em ambientes distribuídos.

O problema com os testes E2E, segundo Newman, é que eles tendem a introduzir acoplamento entre serviços, o que pode dificultar essa independência. Como resultado, os testes E2E podem se tornar um gargalo no ciclo de desenvolvimento, atrasando a implantação de novos recursos e correções.

Newman compartilha uma experiência prática para ilustrar esse ponto:

“Trabalhei em um sistema monolítico, por exemplo, onde tínhamos 4.000 testes de unidade, 1.000 testes de serviço e 60 testes de ponta a ponta. Decidimos que, do ponto de vista do feedback, tínhamos muitos testes de serviço e de ponta a ponta (os últimos dos quais eram os piores infratores em impactar os loops de feedback), então trabalhamos duro para substituir a cobertura do teste por testes de escopo menor."

Ele destaca que os testes de ponta a ponta, apesar de serem apenas 60 em número, foram identificados como os maiores responsáveis por atrasar os ciclos de feedback. O impacto desses testes era tão significativo que a equipe optou por reduzir o número de testes de escopo grande e substituí-los por testes de escopo menor, como testes de unidade e de integração.

Newman também alerta para um antipadrão comum, que ele chama de "cone de neve de teste" ou "pirâmide invertida", onde há poucos ou nenhum teste de escopo pequeno, e toda a cobertura é feita por testes de escopo grande. Ele observa que esse tipo de abordagem resulta em execuções de teste extremamente lentas e ciclos de feedback longos, o que compromete gravemente a eficiência da equipe de desenvolvimento.

Ele continua:

“Esses projetos geralmente têm execuções de teste glacialmente lentas e ciclos de feedback muito longos. Se esses testes forem executados como parte da integração contínua, você não obterá muitas compilações, e a natureza dos tempos de compilação significa que a compilação pode permanecer quebrada por um longo período quando algo quebra.”

Essa observação de Newman reforça a necessidade de se evitar uma dependência excessiva de testes end-to-end, especialmente em ambientes de microserviços. Quando os testes de escopo grande dominam a estratégia de testes, a agilidade do desenvolvimento é comprometida. O tempo necessário para executar esses testes pode se tornar tão longo que, quando algo dá errado, o processo de correção e reexecução se torna ineficaz, resultando em longos períodos de inatividade.

Falta de Confiança nos Resultados: O Impacto dos "Flaky Tests" na Qualidade do Produto

Um dos maiores desafios que equipes de desenvolvimento enfrentam ao implementar suites de testes, especialmente testes end-to-end, é a inconsistência dos resultados, comumente referida como "flaky tests". Esses testes, que falham de maneira imprevisível e sem uma causa aparente, representam um problema significativo. Eles podem exibir resultados diferentes para o mesmo código em diferentes execuções, gerando incertezas e minando a confiança na suite de testes.

A Natureza de Testes Instáveis

"Flaky tests" são uma dor de cabeça para qualquer equipe de desenvolvimento, e seu impacto é amplificado em sistemas complexos, como arquiteturas de microserviços. Esses testes podem passar em uma execução e falhar na próxima, mesmo sem nenhuma alteração no código. Eles falham devido a fatores como dependências externas instáveis, condições de corrida, ou problemas de sincronização. Ok, mas o que a comunidade de engenharia fala sobre esse tipo de problema?

Sam Newman, alerta que os "flaky tests" podem ser um indicativo de que o teste está mal projetado ou que o sistema testado é inerentemente frágil. Quando uma equipe não pode confiar nos resultados de seus testes, isso diminui a eficácia dos testes como ferramenta para garantir a qualidade do software. O tempo e os recursos gastos para investigar falhas de testes que não refletem problemas reais no código são desperdiçados, e isso pode retardar significativamente o desenvolvimento. Abaixo vou deixar algumas palavras dele:

Testes instáveis ​​são o inimigo. Quando falham, não nos dizem muita coisa. Nós executamos novamente nossas compilações de CI na esperança de que elas passem novamente mais tarde, apenas para ver os check-ins se acumularem e, de repente, nos encontramos com uma carga de funcionalidade quebrada.

Quando detectamos testes instáveis, é essencial que façamos o nosso melhor para removê-los. Caso contrário, começamos a perder a fé em um conjunto de testes que "sempre falha assim". Um conjunto de testes com testes instáveis ​​pode se tornar vítima do que Diane Vaughan chama de normalização da desviância — a ideia de que, com o tempo, podemos nos acostumar tanto com as coisas estarem erradas que começamos a aceitá-las como normais e não como um problema. - Sam Newman

Citando novamente Martin Fowler, em seu artigo "Eradicating Non-Determinism in Tests", descreve os "flaky tests" como um dos maiores inimigos de uma suite de testes eficiente. Ele afirma que testes não determinísticos, aqueles que produzem resultados inconsistentes, devem ser identificados e corrigidos o mais rápido possível. Fowler também discute como esses testes podem surgir de várias fontes, como dependências externas (por exemplo, serviços de terceiros), falhas na configuração do ambiente de teste, ou até mesmo sincronizações de tempo inadequadas. Ele sugere que a presença de "flaky tests" é um sinal de alerta, indicando que algo está errado na estratégia de teste ou na própria aplicação.

Custo Operacional e Agilidade

A minha visão sobre esse tema é a seguinte, não há margem para "flaky tests" em qualquer estratégia de testes, especialmente nas mais custosas que ocupam o topo da pirâmide de testes, como os testes E2E. A lógica é simples: testes de unidade e integração podem ser executados rapidamente e ajustados com relativa facilidade. No entanto, testes E2E são caros em termos de tempo de execução, recursos computacionais e manutenção. Se um teste E2E se tornar "flaky", o custo operacional de lidar com ele é exponencialmente maior do que seria para um teste de unidade ou integração.²

Esse custo não se limita apenas ao tempo e recursos financeiros; ele também afeta diretamente a agilidade da equipe. Quando uma equipe não pode confiar nos resultados dos testes, a confiança na pipeline de entrega contínua é corroída. Os engenheiros começam a questionar cada falha, reexecutando testes desnecessariamente e atrasando as entregas. Isso não só diminui a velocidade com que novas funcionalidades podem ser implementadas, mas também prejudica a moral da equipe, que pode se sentir frustrada e desmotivada.

Impacto na Qualidade Final do Produto

Do ponto de vista da qualidade do produto, a presença de "flaky tests" é um risco sério. Quando um teste falha de maneira inconsistente, ele pode mascarar problemas reais no código. Um teste que passa ocasionalmente pode fazer com que um bug significativo passe despercebido, resultando em falhas críticas em produção. Imagine um cenário em que um teste que deveria validar a integridade de uma transação financeira falha intermitentemente devido a um "flaky test". Se esse comportamento chegar à produção, pode causar danos substanciais, tanto em termos financeiros quanto de reputação.

Além disso, a confiança na suite de testes é crucial para o processo de refatoração e melhoria contínua do código. Se os desenvolvedores não podem confiar que os testes capturarão os problemas de forma consistente, eles podem se tornar relutantes em fazer mudanças necessárias no código, por medo de introduzir novos bugs que não serão capturados pelos testes.³

A confiabilidade dos testes end-to-end é fundamental para o sucesso de qualquer projeto de software. Quando esse feedback é comprometido, todo o ciclo de desenvolvimento é afetado.

Para resolver o problema dos "flaky tests", é essencial adotar práticas rigorosas de teste e garantir que cada teste tenha um propósito claro e seja executado em condições controladas. Isso pode envolver a eliminação de dependências externas, a utilização de mocks e stubs para isolar o código testado, e a revisão constante dos testes para garantir que eles permaneçam relevantes e eficazes.

A Erradicação dos "Flaky Tests" é Prioridade

Erradicar os "flaky tests" deve ser uma prioridade para qualquer equipe de desenvolvimento que busca manter a qualidade e a agilidade. Como foi bem destacado, não há margem para esses testes em uma estratégia eficaz de garantia de qualidade, especialmente em testes que estão no topo da pirâmide e são mais custosos. A confiança nos resultados dos testes é a base sobre a qual se constrói a confiança no código e no produto final. Sem essa confiança, todo o processo de desenvolvimento é comprometido, resultando em produtos de qualidade inferior, ciclos de entrega mais longos e uma equipe menos eficiente e motivada.

A adoção de práticas de teste mais rigorosas, combinada com uma revisão contínua e a erradicação de "flaky tests", permitirá que as equipes de desenvolvimento mantenham a integridade de seus testes e continuem entregando software de alta qualidade de forma ágil e eficiente.

Alto Custo de Manutenção: O Desafio de Sustentar um Ambiente de E2E em Microserviços

Manter um ambiente de teste estável e consistente é uma tarefa árdua em qualquer sistema, mas essa complexidade é amplificada em ecossistemas de microserviços. Em uma arquitetura onde cada serviço é independente, mas interconectado, a manutenção dos testes se torna uma tarefa monumental. Esse esforço não envolve apenas o trabalho manual e os recursos técnicos, mas também traz consigo um custo significativo em termos de tempo, qualidade e, potencialmente, o sucesso do produto como um todo.

Complexidade em Ecossistemas de Microserviços

No contexto de uma arquitetura distribuída, cada serviço pode ter suas próprias dependências, configurações e requisitos. Esses serviços frequentemente interagem com múltiplos bancos de dados, APIs externas e outros serviços dentro do mesmo ecossistema. Manter um ambiente de teste estável para cada serviço, e garantir que todas as dependências estejam corretamente configuradas e sincronizadas, pode ser um verdadeiro desafio.

Por exemplo, imagine um serviço que depende de outros três serviços para funcionar corretamente. Se qualquer um desses serviços dependentes estiver fora do ar, com dados inconsistentes ou com uma versão desatualizada, isso pode causar falhas nos testes que não refletem problemas reais no serviço em teste. Pior ainda, alterações manuais no ambiente de teste, como ajustes temporários para "corrigir" problemas, podem introduzir inconsistências que são difíceis de rastrear e corrigir.

Este cenário não é incomum em microserviços, onde a natureza distribuída da arquitetura complica ainda mais o controle de qualidade. Cada mudança em um serviço pode ter efeitos cascata em outros, tornando a depuração e a verificação extremamente difíceis. A combinação de ambientes heterogêneos e a necessidade de configurações específicas aumenta o custo de manutenção e dificulta a identificação de problemas reais.

Custo de Manutenção: Tempo, Valor e Qualidade

O custo de manutenção de uma suite de testes não se limita apenas ao tempo e recursos financeiros necessários para mantê-la. Ele também inclui o impacto na capacidade da equipe de entregar valor de forma contínua e eficiente. Quando os testes requerem manutenção frequente, a equipe pode se encontrar presa em um ciclo interminável de ajustes e correções, consumindo tempo que poderia ser dedicado à implementação de novas funcionalidades ou melhorias.

Mais preocupante ainda, a necessidade constante de manutenção pode levar à negligência na qualidade dos testes. Quando os engenheiros e QA's estão sobrecarregados com a tarefa de manter o ambiente de teste, pode haver uma tendência a "fazer o que for necessário" para passar nos testes, mesmo que isso signifique comprometer a qualidade. Essa abordagem pode resultar em funcionalidades críticas que não são testadas de forma adequada, aumentando o risco de problemas em produção.

Essas falhas podem ser devastadoras. Imagine uma funcionalidade de pagamento que foi lançada com um bug porque os testes foram negligenciados. Isso não só impacta diretamente a confiança dos usuários, mas também pode resultar em perdas financeiras significativas e danos à reputação da empresa.

A Perspectiva dos QA's

Para os QA's, o desafio de manter um ambiente de teste estável é ainda mais pronunciado. Eles são frequentemente os guardiões da qualidade, responsáveis por garantir que o produto final atenda aos padrões exigidos. No livro "The Art of Software Testing", de Glenford Myers, a importância de ambientes de teste estáveis e bem mantidos é destacada como crucial para garantir resultados precisos e confiáveis. Myers enfatiza que, sem um ambiente controlado e consistente, os resultados dos testes podem ser enganosos, levando a uma falsa sensação de segurança.

O autor não discute diretamente microserviços, mas seus princípios sobre a importância da manutenção e qualidade em testes são altamente relevantes para essa arquitetura. Em um ambiente onde os sistemas são distribuídos e cada serviço pode ser desenvolvido e implantado independentemente, o desafio de manter um ambiente de teste estável e confiável se torna ainda mais crítico.

1. Custos de Manutenção: Myers observa que o custo de manutenção de uma suite de testes pode ser alto, mas o custo de não manter essa suite é ainda maior. Em microserviços, isso se traduz em garantir que cada serviço possa ser testado de forma isolada, sem depender de configurações manuais que possam introduzir erros ou inconsistências.

2. Qualidade do Ambiente de Teste: A confiabilidade do ambiente de teste é crucial para a qualidade do software. Isso significa que os ambientes de teste precisam ser configurados de forma automática e consistente, evitando intervenções manuais que possam corromper os dados de teste ou as condições do ambiente.

3. Impacto na Qualidade: Como Myers destaca, a qualidade dos testes está diretamente relacionada à qualidade do produto final. Então garantir a integridade dos testes é fundamental para evitar problemas críticos em produção.

QA's precisam estar constantemente vigilantes para garantir que as alterações no ambiente de teste não corrompam os dados de teste ou introduzam novas variáveis que não foram consideradas. O trabalho manual envolvido em configurar e manter esses ambientes pode ser exaustivo, especialmente em grandes organizações onde múltiplos serviços estão em constante evolução.

Impacto nos Product Managers e Product Owners

Na engenharia de software, tudo envolve custos. Embora Product Managers e Product Owners possam não estar diretamente envolvidos na manutenção dos testes, eles são profundamente afetados por esses desafios. A qualidade dos testes tem um impacto direto na capacidade de entregar novas funcionalidades com confiança. Quando o ambiente de teste é instável, os prazos de entrega se tornam incertos, e a capacidade de responder rapidamente às mudanças nas necessidades do mercado é drasticamente reduzida.

Todos os envolvidos em um projeto de software dependem de ciclos de feedback rápidos e confiáveis para planejar e priorizar as próximas etapas do desenvolvimento. Se os testes são difíceis de manter e geram instabilidade, os prazos se estendem, gerando frustração entre as equipes. Esse desgaste contínuo, causado por constantes replanejamentos e ajustes, pode levar à diminuição da moral da equipe e à perda de confiança na capacidade de entregar valor de forma eficiente.

Além disso, a pressão para cumprir prazos pode levar a decisões apressadas, onde a qualidade é sacrificada em nome da “agilidade”. Isso cria um ciclo vicioso: problemas em produção levam a mais manutenção e ajustes, consumindo ainda mais tempo e recursos. Nesse ponto, a percepção de agilidade pode se transformar em uma ilusão, onde o tempo ganho em entregas rápidas é perdido na resolução de problemas que poderiam ter sido evitados com um ambiente de teste mais robusto.

O Custo Inevitável da Manutenção

Manter a qualidade e a estabilidade em ambientes de microserviços é uma tarefa que envolve custos significativos, e ignorar esses custos pode levar a consequências ainda mais graves. Esses custos não são apenas técnicos; eles permeiam toda a organização. Desde os engenheiros e QA's que lutam para manter os testes funcionando, até os Product Managers e Product Owners que precisam lidar com as consequências dos atrasos e da qualidade comprometida, todos sentem o impacto.

Garantir um ambiente de teste estável e eficiente requer uma abordagem estratégica. Isso inclui a automação sempre que possível, a eliminação de dependências manuais, e a criação de ambientes de teste que possam ser facilmente reproduzidos e configurados de forma consistente. Investir na qualidade dos testes e na manutenção do ambiente desde o início pode parecer um custo alto, mas é um investimento necessário. O custo de não fazer isso é muito maior, tanto em termos de tempo quanto de impacto no produto final e na confiança dos clientes.

Portanto, a lição é clara: a qualidade não pode ser comprometida. O custo de manter um ambiente de testes estável e eficaz é inevitável, mas o custo de não manter essa qualidade é ainda maior. Garantir que os testes sejam confiáveis, consistentes e bem mantidos é essencial para entregar um produto que não apenas atenda às expectativas, mas que também seja capaz de resistir ao tempo e às mudanças inevitáveis no mundo do desenvolvimento de software.

Calculando o Tempo de Execução dos Testes End-to-End: Um Exemplo Teórico

Vamos pegar um exemplo hipotético, mas que poderia facilmente se aplicar a muitos cenários reais. Suponha que estamos trabalhando em um microserviço responsável por gerenciar vouchers. Esse serviço possui cinco endpoints principais:

1. Criar Vouchers (POST /vouchers)

2. Validar Voucher (GET /vouchers/{id}/validate)

3. Aplicar Voucher (POST /vouchers/{id}/apply)

4. Cancelar Voucher (POST /vouchers/{id}/cancel)

5. Consultar Vouchers (GET /vouchers)

Agora, considere que uma mudança foi realizada na lógica de aplicação dos vouchers (no endpoint /vouchers/{id}/apply). Embora a alteração tenha sido específica para este endpoint, como estamos lidando com um sistema legado sem uma clara segregação das regras de negócio, é prudente testar todos os endpoints para garantir que a mudança não introduziu problemas em outras áreas do serviço.

Em cenários como esse, as regras de negócio podem ser bastante complexas, especialmente quando se trata de garantir a integridade dos vouchers. Por exemplo, um usuário pode precisar estar autenticado ou autorizado para acessar certos recursos, e uma simples chamada de GET pode ter inúmeras verificações de segurança antes de retornar um resultado. Além disso, o serviço pode fazer chamadas assíncronas para outros sistemas para validar informações em tempo real, o que adiciona ainda mais tempo ao processo de teste.

Vamos considerar os seguintes detalhes para os testes E2E, lembrando que o exemplo é totalmente hipotético:

• Número de cenários de teste por endpoint: 10 cenários para cada endpoint.

• Tempo médio de execução por step: 800ms (0,8 segundos) por step.

• Número de steps por cenário: 10 steps (sendo que 2 steps em cada cenário envolvem uma pausa de 15 segundos para chamadas assíncronas ou outras verificações).

Agora, vamos calcular o tempo total necessário para executar todos os cenários de teste para este serviço:

Tempo por cenário (sem as pausas de 15 segundos):

\(\text{Tempo sem espera} = 8 \times 0,8 \text{ segundos} = 6,4 \text{ segundos} \)

Tempo de execução com as pausas de 15 segundos:

\(\text{Tempo de espera} = 2 \times 15 \text{ segundos} = 30 \text{ segundos}\)

Tempo total por cenário:

\(\text{Tempo total por cenário} = 6,4 \text{ segundos} + 30 \text{ segundos} = 36,4 \text{ segundos}\)

Tempo total para todos os cenários de um endpoint (10 cenários):

\(\text{Tempo total por endpoint} = 10 \times 36,4 \text{ segundos} = 364 \text{ segundos} \approx 6,07 \text{ minutos}\)

Tempo total para todos os endpoints (5 endpoints):

\(\text{Tempo total para todos os endpoints} = 5 \times 364 \text{ segundos} = 1820 \text{ segundos} \approx 30,33 \text{ minutos}\)

Assim, o tempo total para executar todos os cenários de teste end-to-end para este serviço seria aproximadamente 30,33 minutos. Embora isso possa parecer gerenciável em uma única execução, lembre-se de que este é apenas um serviço em um ecossistema potencialmente grande de microserviços. Se aplicarmos essa lógica a um sistema com muitos microserviços, o tempo necessário para validar todas as integrações pode rapidamente se tornar um gargalo significativo.

Impacto na Produtividade e no Ciclo de Desenvolvimento

O que acontece quando você multiplica isso por vários serviços? E se houver uma falha nos testes que exija múltiplas execuções? Esses 30,33 minutos. podem rapidamente se transformar em horas, especialmente quando há necessidade de debug e reexecução dos testes.

Mais importante ainda, se a suite de testes falhar devido a uma regra de negócio mal definida ou uma configuração de ambiente incorreta, todo o fluxo de desenvolvimento pode ser interrompido. Isso é especialmente frustrante em sistemas legados, onde o tempo necessário para isolar e corrigir o problema pode ser significativo.

Esses atrasos não só afetam a produtividade dos engenheiros, que ficam aguardando o feedback dos testes, mas também impactam a entrega de valor ao cliente. Cada minuto gasto na espera de resultados de testes que poderiam ter sido otimizados é um minuto a menos dedicado ao desenvolvimento de novas funcionalidades ou à melhoria da qualidade do código.

A Realidade das Regras de Negócio Complexas

Outro ponto crucial a considerar é que, dependendo das regras de cada corporação, um serviço de vouchers pode ter muito mais cenários de erros e regras complexas para garantir a integridade dos vouchers. Por exemplo, uma simples operação de GET para listar vouchers pode exigir que o usuário esteja autenticado, que tenha permissões específicas, e que o sistema valide o status dos vouchers em tempo real. Cada uma dessas verificações adiciona camadas de complexidade aos testes e aumenta o tempo total necessário para validá-los.

Além disso, em ambientes onde a comunicação assíncrona é prevalente, como em microserviços que utilizam filas de mensagens ou eventos para processar dados, a depuração de falhas nos testes pode se tornar extremamente complexa. Muitas vezes, é difícil conectar uma falha a sua causa real, como uma mensagem que não foi enviada para uma fila, resultando em comportamentos inesperados em outras partes do sistema.

Para engenheiros de software e líderes de equipe, medir o tempo de execução dos testes E2E e monitorar a quantidade de tempo gasto em esperas ou na depuração de falhas é essencial para identificar gargalos que afetam a produtividade. Ao analisar esses tempos, é possível entender melhor onde o processo de testes pode ser otimizado.

Por exemplo, se o tempo de execução dos testes começa a impactar a entrega contínua, pode ser necessário dividir a suite de testes ou adotar abordagens diferentes de testes para verificar comportamentos básicos. Vamos conversar bastante sobre esse tema em breve.

Dificuldade em Identificar a Causa das Falhas: O Desafio da Depuração em Ambientes Assíncronos

Onde a comunicação assíncrona existe, depurar falhas pode se tornar uma tarefa extremamente complexa e frustrante. Imagine um cenário hipotético em que uma grande aplicação é composta de dezenas de microserviços, muitos dos quais se comunicam através de filas de mensagens como RabbitMQ ou Kafka. Agora, visualize que você está rodando uma suite de testes end-to-end para validar um fluxo de negócio crítico, como o processamento de uma transação financeira.

O Processo de Pagamento

Vamos imaginar um fluxo de pagamento. Suponha que o Serviço A recebe a requisição de um pagamento, processa os dados iniciais e, em seguida, envia uma mensagem para uma fila para que o Serviço B realize uma validação antifraude. O Serviço B, ao concluir sua validação, envia outra mensagem para o Serviço C, que realiza o débito na conta do usuário e finaliza a transação.

Agora, durante a execução dos testes end-to-end, ocorre uma falha. O sistema não completou o pagamento, e o teste falhou. Mas, por que isso aconteceu? Essas são algumas perguntas que um engenheiro de software precisará responder:

• Será que o Serviço A não conseguiu enviar a mensagem para a fila?

• Ou o Serviço B estava indisponível no momento, e a mensagem foi perdida ou ignorada?

• Ou talvez o Serviço C recebeu a mensagem, mas não conseguiu acessar o banco de dados para completar o débito?

Cada uma dessas etapas é assíncrona e pode ter falhado de forma independente, complicando a identificação da causa raiz.

Pense comigo: como você identificaria a causa exata dessa falha? Como você conectaria uma mensagem não enviada, ou recebida fora de ordem, com um erro na transação final? Quanto tempo você gastaria tentando rastrear a origem do problema? E mais importante, como isso afeta sua capacidade de focar em desenvolver novas funcionalidades ou melhorar a arquitetura existente?

Este cenário revela uma das armadilhas dos testes end-to-end em sistemas complexos. A natureza distribuída dos microserviços, combinada com a comunicação assíncrona, cria uma teia de interações que são difíceis de monitorar e depurar. Quando um teste falha, pode não ser imediatamente claro onde está o problema. Isso não só consome tempo, mas também frustra os engenheiros e analistas de qualidade, que precisam lidar com falhas que podem não refletir problemas reais no código.

A Dor de Cabeça das Mensagens em um DLQ

Agora, considere um cenário específico: o Serviço A envia uma mensagem para a fila, mas por alguma razão — talvez uma configuração errada, uma falha temporária na rede, ou uma indisponibilidade do Serviço B — essa mensagem nunca chega ao seu destino. O Serviço B, então, não processa a transação, e o Serviço C nunca recebe o comando para debitar a conta do cliente. Quando o teste falha, tudo o que você vê é que a transação não foi completada e a mensagem na DLQ do broker. Mas a causa raiz, uma mensagem perdida, pode estar escondida várias camadas abaixo da superfície.

Esse tipo de problema não é apenas difícil de identificar; é também uma dor de cabeça para corrigir. Você pode passar minutos ou horas verificando logs, testando novamente, e ajustando configurações apenas para descobrir que o problema estava em uma pequena falha de comunicação entre os serviços. E, se essa falha for intermitente, pode passar despercebida em alguns testes, mas não em outros, tornando a depuração ainda mais complexa.

Simulação versus Realidade

Diante desse desafio, alguns engenheiros podem optar por simular certos serviços ou filas para tornar os testes mais previsíveis e menos sujeitos a falhas causadas por indisponibilidades temporárias ou erros de configuração. Mas aqui surge uma pergunta importante: ao simular essas interações, estamos realmente testando de ponta a ponta?

A simulação pode ser apropriada para testes de unidade ou de integração, onde você deseja isolar componentes e garantir que eles funcionem corretamente de forma independente. No entanto, nos testes end-to-end, o objetivo é verificar se todo o fluxo de negócios, incluindo a comunicação entre serviços, funciona corretamente em um ambiente o mais próximo possível do real. Se você começar a substituir partes críticas do sistema por simulações, estará comprometendo a integridade desses testes.

Por isso fique atento e sempre se questione e avalie a necessidade de utilizar ou não as simulações.

O Tempo e a Complexidade dos Testes Assíncronos

Considerando que os testes end-to-end em ambientes assíncronos podem demorar significativamente para serem executados, o impacto no ciclo de desenvolvimento é real. Cada vez que um teste falha, os engenheiros precisam gastar tempo investigando, o que retarda a entrega de novas funcionalidades e pode aumentar a pressão para comprometer a qualidade. Além disso, os testes E2E que dependem de comunicação assíncrona podem ser difíceis de paralelizar, aumentando ainda mais o tempo total de execução.

Se os testes demoram para rodar e as falhas não são claramente identificáveis, você está diante de um gargalo que pode comprometer todo o processo de desenvolvimento ágil. O tempo que você gasta depurando esses testes é tempo que poderia ser usado para melhorar o código, refatorar componentes, ou adicionar novas funcionalidades que agregam valor ao negócio.

O Custo Oculto das Falhas em Ambientes Assíncronos

Depurar falhas em sistemas com comunicação assíncrona é um desafio que requer cuidado, paciência e uma abordagem estruturada. A complexidade de identificar a causa raiz das falhas não só afeta o tempo de desenvolvimento, mas também pode desmotivar os engenheiros e analistas de qualidade. A falta de clareza sobre onde está o problema pode levar a ciclos de desenvolvimento mais longos, maior frustração na equipe, e, em última instância, a uma redução na qualidade do produto final.

É crucial que, ao planejar uma suite de testes end-to-end, as equipes levem em consideração esses desafios e ponderem a melhor forma de testá-los. Simulações podem ser úteis em certos contextos, mas é essencial entender as limitações que elas impõem. O objetivo final deve ser sempre garantir que o sistema funcione como esperado no mundo real, onde as comunicações assíncronas e os possíveis erros são inevitáveis.

Atraso na Entrega de Valor: O Impacto dos Testes End-to-End no Ciclo de Desenvolvimento

Quando uma organização adota uma arquitetura de microserviços, um dos objetivos principais é permitir que diferentes equipes trabalhem de forma independente, entregando valor de forma contínua e ágil. No entanto, em grandes times, onde múltiplas equipes podem estar trabalhando em serviços interdependentes, os testes end-to-end podem se tornar um ponto de contenção significativo. Isso é especialmente verdade quando commits de código são acumulados, aguardando para passar pela suite de testes E2E, resultando em atrasos na integração contínua e, consequentemente, na entrega de novas funcionalidades ou correções ao cliente.

O Dilema dos Testes End-to-End em Ambientes Distribuídos: Conflitos de Interesses e Incompatibilidades

Visualize uma grande corporação (se você já não trabalha em uma ) onde várias equipes estão desenvolvendo serviços que, embora independentes, precisam se integrar para entregar uma funcionalidade completa. Cada equipe realiza seus commits e, antes de qualquer coisa ser implantada em produção, os testes end-to-end precisam ser executados. Se um desses testes falha, seja devido a um problema de configuração, uma dependência não resolvida, ou até mesmo um "flaky test", todos os commits podem ficar parados até que o problema seja resolvido.

Isso cria um cenário onde o progresso de uma equipe depende do sucesso dos testes de outra. Mesmo que uma equipe tenha completado sua parte do trabalho, ela não pode avançar se um teste de outro serviço falhar. Como resultado, a entrega de valor ao cliente é retardada, e a promessa de integração contínua é comprometida.

Esse cenário pode levar a conflitos de interesse entre as equipes. Por exemplo, uma equipe pode estar pronta para lançar uma nova versão de seu serviço, mas outra equipe ainda está ajustando seus testes E2E para acomodar uma nova funcionalidade ou corrigir um bug. Esse tipo de incompatibilidade pode resultar em atrasos significativos, onde o código pronto para ser implantado é mantido em espera, possivelmente por dias ou até semanas, até que todas as equipes estejam alinhadas.

Martin Fowler, em seu artigo sobre Continuous Integration, destaca que o objetivo da integração contínua é evitar exatamente esse tipo de acúmulo de código não integrado. Ele sugere que um dos maiores benefícios da integração contínua é detectar conflitos e problemas o mais cedo possível, mas quando os testes E2E se tornam um gargalo, esse benefício é perdido. Em vez disso, os problemas são descobertos tarde no processo, aumentando a complexidade e o tempo necessário para resolvê-los.

Um Problema Real

Imagine que uma equipe está desenvolvendo uma nova funcionalidade de login com autenticação multifator (MFA) em um grande sistema de microserviços. A equipe de segurança já implementou e testou a lógica do MFA em seu serviço, mas agora os testes end-to-end precisam ser executados para garantir que essa nova funcionalidade funcione em conjunto com todos os outros serviços, como o gerenciamento de contas, o serviço de notificações, e o sistema de pagamentos.

No entanto, os testes E2E falham devido a um problema na integração entre o serviço de MFA e o sistema de notificações, que ainda não foi atualizado para lidar com as novas mensagens enviadas pelo MFA. Até que esse problema seja resolvido, nenhum commit pode avançar para produção. Como resultado, todos os outros serviços que dependem de MFA, como o serviço de pagamentos, também ficam bloqueados.

Esse atraso pode ter um impacto direto na capacidade da empresa de responder rapidamente a requisitos de conformidade, afetando não apenas a entrega de valor ao cliente, mas também a segurança geral do sistema.

O Impacto nos Engenheiros e Product Managers

Esse tipo de gargalo pode ser frustrante tanto para engenheiros quanto para Product Managers e Product Owners. Para os engenheiros, a sensação de ter seu trabalho bloqueado por um problema fora de seu controle pode ser desmotivadora e levar à perda de foco. Em vez de avançar para a próxima tarefa, eles se veem presos na resolução de problemas que, muitas vezes, não são diretamente relacionados ao que estavam desenvolvendo.

Para Product Managers e Product Owners, esses atrasos podem comprometer prazos e metas, dificultando a entrega de valor aos clientes no tempo esperado. Eles precisam lidar com stakeholders ansiosos, replanejar releases, e talvez até ajustar prioridades de desenvolvimento, tudo devido a problemas que surgiram tardiamente no ciclo de desenvolvimento.

Otimizando a Entrega de Valor

O uso de testes end-to-end é essencial para garantir que todos os serviços funcionem em harmonia, mas quando esses testes se tornam um gargalo, é hora de reconsiderar a estratégia. Uma possível solução é integrar testes de contrato e de integração que possam validar as interações entre serviços de forma mais isolada e eficiente, permitindo que as equipes avancem de forma independente, sem esperar pelos resultados de testes E2E.

Michael Feathers, em Working Effectively with Legacy Code, menciona que a verdadeira eficácia dos testes não está em testar tudo de uma vez, mas em testar de forma que cada componente seja validado em seu próprio contexto. Isso pode aliviar a pressão sobre os testes E2E e garantir que eles sejam usados apenas para validar os fluxos críticos de negócio, sem impedir a entrega contínua de valor.

Baixa Eficiência na Identificação de Bugs: O Dilema dos Testes End-to-End

A afirmação de que os testes end-to-end podem ser ineficazes na identificação de bugs pode parecer contraditória à primeira vista. Afinal, esses testes cobrem o sistema de forma abrangente, simulando interações do usuário final e validando fluxos completos de negócios. No entanto, essa percepção se torna mais compreensível quando analisamos tanto do ponto de vista técnico quanto de negócios.

A Complexidade dos Testes End-to-End e a Ineficiência na Detecção de Bugs

Do ponto de vista técnico, os testes E2E são, sem dúvida, trabalhosos de se escrever e manter. Isso se deve à necessidade de cobrir múltiplos cenários e garantir que todas as possíveis interações entre os componentes do sistema sejam testadas. No entanto, é justamente essa complexidade que pode limitar sua eficácia na detecção de bugs.

Por exemplo, uma feature que pode parecer simples na superfície — como a atualização de informações do perfil do usuário — pode, na verdade, ter várias regras de negócios subjacentes que precisam ser consideradas. Já trabalhou em uma funcionalidade assim? Que parecia fácil mas ao entrar no código existiam várias verificações importantes que não podiam de maneira nenhuma ser quebradas? Considere isso, uma feature permite ao usuário atualizar seu endereço, mas somente se ele for verificado, e a atualização só pode ocorrer se não houver transações pendentes. Cada uma dessas regras de negócio precisa ser testada, e um teste E2E deve cobrir todas essas condições. Isso significa que múltiplos cenários de teste precisam ser criados, cada um com suas próprias dependências e interações.

Escrever um teste E2E que cubra todas essas nuances pode ser extremamente difícil e trabalhoso. E, mesmo que o teste seja bem escrito, ele ainda pode falhar em capturar certos comportamentos, especialmente aqueles que ocorrem em condições específicas ou raras. Isso pode resultar em um baixo número de bugs detectados, apesar do esforço significativo investido na criação e manutenção desses testes.

Do Ponto de Vista de Negócios: Claridade nas Regras de Negócio e Comunicação

A eficiência dos testes E2E também depende da clareza das regras de negócios e da comunicação entre as equipes de desenvolvimento e qualidade. Se as regras de negócio não forem bem definidas ou se não houver uma compreensão compartilhada entre os engenheiros e os QA's sobre o que precisa ser testado, os testes podem acabar sendo superficiais e não capturarem os detalhes críticos.

No contexto dos negócios, a baixa eficiência na detecção de bugs significa que problemas críticos podem passar despercebidos até chegarem ao ambiente de produção, onde o custo para corrigi-los é muito maior. Além disso, o tempo e os recursos investidos em executar esses testes podem não se justificar se o retorno em termos de bugs detectados for baixo.

Essa situação levanta uma questão importante: será que os testes end-to-end são realmente a melhor abordagem para garantir a qualidade do software? Ou será que outras estratégias, como os testes de contrato, poderiam complementar os testes E2E e oferecer uma maneira mais eficaz de capturar bugs?

A Perspectiva de Martin Fowler: Testes de Contrato como Complemento

Martin Fowler, em seus escritos sobre a pirâmide de testes, sugere que uma abordagem equilibrada pode ser mais eficaz do que depender exclusivamente de testes de ponta a ponta. Ele cita a utilização de testes de contrato como uma estratégia complementar. Os testes de contrato verificam as interações entre diferentes serviços, garantindo que as expectativas de cada serviço sejam cumpridas.

Essa abordagem é particularmente útil em arquiteturas de microserviços, onde a comunicação entre serviços pode ser complexa e suscetível a falhas. Os testes de contrato podem ajudar a capturar bugs relacionados a problemas de integração antes que eles causem falhas nos testes E2E, o que pode tornar o processo de depuração muito mais simples e eficiente.

Outro ponto a considerar é que escrever testes E2E realmente eficazes requer uma compreensão profunda dos fluxos de negócio e das possíveis exceções e condições de borda. Isso pode ser um desafio significativo, especialmente em sistemas complexos. A tentativa de capturar todos os possíveis cenários pode resultar em uma suite de testes inflada, onde muitos casos são superficialmente cobertos, sem realmente agregar valor significativo ao processo de validação.

A ineficiência dos testes end-to-end na identificação de bugs pode, portanto, ser resultado de uma combinação de fatores: complexidade técnica, falta de clareza nas regras de negócio, e a dificuldade inerente de escrever testes que cubram todos os cenários possíveis de maneira eficaz.

Testes de Contrato: Desafios, Receios e Um Exemplo Prático

Quando se fala em testes de contrato, alguns engenheiros de software e líderes técnicos podem ficar com um pé atrás. A mudança para essa abordagem pode parecer intimidante e é natural que surjam dúvidas. Vamos abordar algumas dessas preocupações comuns e explorar o que realmente está envolvido na adoção de testes de contrato.

Visões Erradas Sobre Testes de Contrato

Testes de Contrato Adicionam Complexidade Desnecessária? Uma das primeiras reações que se ouve é: "Isso vai complicar tudo." Parece que, ao adicionar testes de contrato, estamos adicionando uma carga extra de trabalho para manter os testes funcionando. Mas o que realmente acontece é o oposto. Pense nos testes de contrato como uma forma de distribuir a responsabilidade de verificação entre os serviços, aliviando a pressão sobre os testes end-to-end.

Imagine que você tem uma rede de serviços interconectados. Sem testes de contrato, todos os problemas potenciais têm que ser capturados nos testes E2E, que acabam se tornando pesados e demorados. Com os testes de contrato, essas falhas de integração são capturadas logo no início, muito antes de chegarem ao estágio de um teste E2E.

Testes de Contrato São Difíceis de Escrever? Outro receio é que escrever testes de contrato seja uma tarefa árdua, que exija um esforço adicional. Pode parecer complicado no início, especialmente porque precisamos entender os papéis de consumidor e provedor. Mas a realidade é que, com ferramentas como o Pact, esse processo se torna bem mais simples. Essas ferramentas ajudam a automatizar a criação e a verificação dos contratos, tornando o processo de teste mais suave e eficiente.

Por exemplo, com o Pact, você pode criar testes tanto para o consumidor quanto para o provedor. Veja como isso pode funcionar em um cenário real:

// Teste de contrato para um consumidor frontend que consome dados de perfil de usuário
@Pact(consumer = "UserProfileFrontend")
public RequestResponsePact createPact(PactDslWithProvider builder) {
    return builder
        .given("User with ID 123 exists")
        .uponReceiving("A request to retrieve user profile details")
        .path("/api/users/123")
        .method("GET")
        .willRespondWith()
        .status(200)
        .body("{\"id\": 123, \"name\": \"Alice\", \"email\": \"alice@example.com\", \"status\": \"ACTIVE\"}")
        .toPact();
}

@Test
@PactTestFor(providerName = "UserProfileAPI", port = "8080")
public void testGetUserProfilePact() {
    WebClient webClient = WebClient.create("http://localhost:8080");

    UserProfile response = webClient.get()
        .uri("/api/users/123")
        .retrieve()
        .bodyToMono(UserProfile.class)
        .block();

    assertNotNull(response);
    assertEquals(123, response.getId());
    assertEquals("Alice", response.getName());
    assertEquals("alice@example.com", response.getEmail());
    assertEquals("ACTIVE", response.getStatus());
}

Aqui, o teste está validando se o consumidor (neste caso, um frontend) recebe os dados corretos de um provedor (API de usuários). Esse contrato será verificado pelo provedor para garantir que a API retorne as informações corretas.

Testes de Contrato Não São Necessários em Ecossistemas Pequenos? Alguns engenheiros acreditam que se o ecossistema de microserviços é pequeno, os testes de contrato são um luxo desnecessário. Mas essa é uma visão míope. À medida que o sistema cresce, a falta de contratos pode resultar em falhas de comunicação que só serão detectadas em estágios mais avançados, como nos testes E2E ou, pior, em produção.

Mesmo em um ambiente pequeno, é benéfico introduzir testes de contrato desde o início. Isso não só estabelece boas práticas, como também prepara o terreno para um crescimento mais organizado e seguro.

Receios Comuns na Adoção de Testes de Contrato

Manutenção de Consumidor e Provedor: Um dos receios mais comuns é a necessidade de manter os dois lados do contrato: o consumidor e o provedor. E sim, isso significa que haverá um esforço extra. No entanto, a manutenção pode ser altamente automatizada e integrada ao pipeline de CI/CD. O verdadeiro benefício aqui é a visibilidade que os testes de contrato proporcionam. Quando um serviço muda, o contrato ajuda a identificar rapidamente quais consumidores serão impactados, facilitando a coordenação entre equipes.

Perda de Flexibilidade: Outro receio é que os testes de contrato possam limitar a capacidade de inovação ou de mudanças rápidas. Mas os contratos são projetados para permitir flexibilidade dentro de limites aceitáveis. Novos contratos podem ser introduzidos, enquanto as versões anteriores são mantidas até que todos os consumidores estejam prontos para a transição. Isso permite que os serviços evoluam sem interrupções.

Receio de Sobrecarga Inicial: Implementar testes de contrato em um sistema já em produção pode parecer uma tarefa monumental. Muitos preferem adiar até um "momento mais apropriado", que frequentemente nunca chega. A verdade é que os testes de contrato não precisam ser implementados de uma só vez. Eles podem ser introduzidos gradualmente, começando pelos serviços mais críticos ou por novas funcionalidades.

Para ilustrar melhor, considere o exemplo de um consumidor API:

// Teste de contrato para um consumidor API que processa pedidos de compra
@Pact(consumer = "OrderProcessingService")
public RequestResponsePact createOrderProcessingPact(PactDslWithProvider builder) {
    return builder
        .given("Product with ID 456 is available in stock")
        .uponReceiving("A request to place an order for a product")
        .path("/api/orders")
        .method("POST")
        .body("{\"productId\": 456, \"quantity\": 3, \"userId\": 789}")
        .willRespondWith()
        .status(201)
        .body("{\"orderId\": 1010, \"status\": \"CONFIRMED\", \"estimatedDelivery\": \"2024-09-15\"}")
        .toPact();
}

@Test
@PactTestFor(providerName = "OrderAPIProvider", port = "8080")
public void testCreateOrderPact() {
    WebClient webClient = WebClient.create("http://localhost:8080");

    OrderResponse response = webClient.post()
        .uri("/api/orders")
        .bodyValue(new OrderRequest(456, 3, 789))
        .retrieve()
        .bodyToMono(OrderResponse.class)
        .block();

    assertNotNull(response);
    assertEquals(1010, response.getOrderId());
    assertEquals("CONFIRMED", response.getStatus());
    assertEquals("2024-09-15", response.getEstimatedDelivery());
}

Neste segundo exemplo, temos um serviço de processamento de pedidos que consome uma API para criar novos pedidos. O contrato assegura que, ao criar um pedido para um produto disponível em estoque, a API responderá com um status de "CONFIRMED" e uma data estimada de entrega, validando assim a integridade da transação.

Ao superar os receios iniciais, os testes de contrato oferecem vantagens inquestionáveis. Eles permitem detecção precoce de problemas, facilitam a comunicação entre equipes e reduzem a carga dos testes E2E. Com o tempo, eles podem se tornar uma parte integral e valiosa do ciclo de desenvolvimento.

É claro que a adoção de testes de contrato exige um esforço inicial, mas esse investimento paga dividendos em termos de estabilidade, confiabilidade e capacidade de escalar o sistema de forma segura. Para quem ainda está relutante, a melhor abordagem é começar pequeno, com serviços críticos, e expandir conforme a equipe ganha confiança na prática.

Mas talvez prefira uma abordagem com várias estratégias de testes.

Uma Abordagem Combinada: Testes de Contrato e Testes de Aceitação

Quando falamos em garantir a qualidade de sistemas complexos, precisamos de várias estratégias de testes que sejma eficientes e abrangentes. No caso do Nubank, esse desafio se tornou evidente à medida que a empresa crescia, e eles perceberam que sua dependência de testes end-to-end estava se tornando um grande gargalo. Em resposta a isso, o Nubank adotou uma estratégia combinada de testes de contrato e testes de aceitação, que se mostrou mais eficaz e escalável.

No artigo "Why We Killed Our End-to-End Test Suite: How Nubank Switched to a Contract and Acceptance Testing Strategy to Scale to Over 1k Engineers", o Nubank detalha os problemas que enfrentou ao depender exclusivamente de E2E. Com uma suite de testes que cobria um grande número de cenários de ponta a ponta, eles começaram a notar uma série de desafios:

• Lentidão na Execução dos Testes: Com a expansão da base de código, os testes E2E começaram a levar cada vez mais tempo para serem executados. Isso retardava o ciclo de feedback, afetando a agilidade da equipe.

• Falta de Confiabilidade nos Resultados: Muitos dos testes end-to-end eram instáveis, falhando de forma inconsistente e gerando um alto número de falsos positivos, o que diminuía a confiança da equipe na suite de testes.

• Alto Custo de Manutenção: Manter a suite de testes E2E era uma tarefa trabalhosa e cara, especialmente à medida que o número de microserviços crescia e as interações entre eles se tornavam mais complexas.

Diante desses problemas (que já discutimos neste artigo), o Nubank decidiu mudar sua abordagem para uma combinação de testes de contrato e aceitação.

O Que São Testes de Aceitação?

Testes de aceitação são projetados para validar se um sistema ou funcionalidade atende aos requisitos de negócio e às expectativas das partes interessadas. Eles se concentram em verificar se o software cumpre os critérios de aceitação previamente definidos, simulando cenários reais de uso para garantir que tudo funcione conforme esperado.

A estrutura de um teste de aceitação geralmente envolve os seguintes elementos:

1. Critérios de Aceitação: São definidos em colaboração com stakeholders, como Product Owners, analistas de negócios e engenheiros de software. Eles especificam exatamente o que precisa ser validado para que uma funcionalidade seja considerada completa e pronta para ser entregue.

2. Ambiente de Teste: Testes de aceitação são realizados em um ambiente que replica o mais próximo possível o ambiente de produção. Isso garante que os resultados do teste sejam representativos do comportamento real do sistema.

3. Cenários de Teste: Cada critério de aceitação é traduzido em um ou mais cenários de teste, que descrevem passo a passo as interações do usuário com o sistema. Esses cenários podem incluir variáveis diferentes, como tipos de usuário, permissões, ou condições específicas.

4. Execução e Validação: Os cenários de teste são então executados, e os resultados são comparados com os critérios de aceitação para determinar se a funcionalidade está implementada corretamente.

Por exemplo, em um sistema de reservas de voos, um teste de aceitação poderia garantir que, ao selecionar um voo e aplicar um voucher, o desconto é aplicado corretamente, o assento é reservado, e uma confirmação é enviada ao usuário. Esses testes são cruciais para garantir que as regras de negócio sejam cumpridas e que o produto final esteja em conformidade com as expectativas dos stakeholders.

Uma Estratégia Combinada

Essa abordagem combinada também pode ser aplicada em outros contextos. Imagine que você está trabalhando com um microserviço responsável por gerenciar vouchers, como discutimos anteriormente. Ao adotar uma combinação de testes de contrato, aceitação e E2E, você pode:

• Testes de Contrato: Garantir que a API do serviço de vouchers funcione corretamente com outros serviços, como o de autenticação ou de pagamentos, validando que todos os parâmetros necessários estão presentes e corretamente formatados.

• Testes de Aceitação: Validar que as principais regras de negócio estão sendo seguidas, como garantir que um voucher não pode ser aplicado a uma compra já concluída, ou que os usuários só podem aplicar um voucher se estiverem autenticados.

• Testes End-to-End: Validar o fluxo completo de compra com a aplicação de um voucher, desde a seleção do produto até a confirmação do pagamento, garantindo que todas as etapas do processo funcionem em conjunto como esperado.

A decisão do Nubank de reduzir a dependência dos testes end-to-end e adotar uma estratégia combinada de testes de contrato e aceitação foi fundamental para escalar sua base de código e equipe de engenharia de forma eficiente. Esse movimento não apenas melhorou a eficiência dos testes, mas também permitiu que a empresa mantivesse a qualidade do software enquanto continuava a crescer.

Para corporações financeiras e outras organizações enfrentando desafios semelhantes, a lição é de que uma abordagem combinada de testes pode oferecer uma maneira mais eficaz de garantir a qualidade do software, reduzindo os gargalos e mantendo a agilidade necessária para entregar valor continuamente aos clientes.

Conclusão

Será que os testes de ponta a ponta são um problema em microserviços, a ponto de sugerirmos sua exclusão completa? A resposta não é simples, e como discutimos ao longo deste artigo, não se trata de atacar a estratégia E2E ou considerá-la obsoleta. Em vez disso, estamos destacando que essa abordagem, quando mal utilizada ou sobrecarregada, pode introduzir desafios significativos, especialmente em arquiteturas complexas.

Os testes E2E têm seu lugar no processo de desenvolvimento, pois fornecem uma visão abrangente de como diferentes componentes do sistema trabalham juntos para cumprir um fluxo de negócios. No entanto, o problema surge quando eles são vistos como a solução definitiva para garantir a qualidade. Como vimos através das opiniões de engenheiros renomados e do case de sucesso do Nubank, simplesmente inverter a pirâmide de testes, colocando a maior parte da confiança nos testes E2E, não resulta necessariamente em maior qualidade ou confiança.

Reflexões sobre os Desafios dos Testes de Ponta a ponta:

1. Complexidade e Custo: Os testes E2E, por sua natureza, são complexos e caros de manter. Eles envolvem múltiplas dependências e muitas vezes sofrem com instabilidades, como os "flaky tests", que podem gerar falsos positivos ou negativos. Isso não só consome tempo e recursos, mas também afeta a agilidade da equipe de desenvolvimento.

2. Feedback Lento: Aumentar a dependência dos testes E2E pode levar a um ciclo de feedback mais lento. Em vez de receber respostas rápidas sobre mudanças no código, as equipes ficam esperando por horas para que toda a suite de testes seja executada. Esse atraso pode comprometer a capacidade de fazer iterações rápidas e entregar valor contínuo.

3. Confiança e Qualidade: Inverter a pirâmide de testes e depender excessivamente dos E2E pode criar uma falsa sensação de segurança. Embora esses testes validem o comportamento do sistema como um todo, eles nem sempre capturam falhas em nível granular, como problemas de integração entre microserviços que poderiam ser identificados mais facilmente com testes de contrato ou unitários.

4. Atenção aos Cenários de Negócio: Testes E2E devem ser reservados para validar fluxos de negócios críticos e não para cobrir todos os cenários possíveis. Ao focar os E2E em testes essenciais, enquanto delegamos as verificações de integração e comportamento básico aos testes de contrato e unitários, conseguimos uma estratégia de testes mais eficiente e menos propensa a gargalos.

Perguntas para Reflexão:

• Será que sua equipe está utilizando os testes E2E de maneira eficiente, ou eles estão se tornando um gargalo na entrega de valor?

• Como você pode equilibrar a carga entre testes unitários, de contrato, e E2E para obter feedback rápido e manter a qualidade sem sacrificar a agilidade?

• Existe uma oportunidade de adotar práticas como as implementadas pelo Nubank, que combinam testes de contrato com E2E para alcançar um ciclo de desenvolvimento mais fluido e confiável?

Testes end-to-end não são o problema em si; o problema reside em como eles são aplicados e sobrecarregados em sistemas complexos como os de microserviços. São uma ferramenta poderosa, mas, como qualquer ferramenta, seu uso deve ser cuidadosamente considerado e balanceado com outras abordagens de teste. Ao integrar testes de contrato e unitários, e ao reservar os testes E2E para cenários de negócio realmente críticos, podemos manter a agilidade no desenvolvimento e garantir que o produto final seja robusto e confiável.

A decisão de como aplicar testes end-to-end em sua arquitetura depende do contexto específico e dos desafios que você enfrenta. É importante refletir sobre os objetivos de seu sistema, as necessidades de negócio e a estrutura de sua equipe para definir a estratégia de teste que melhor se adapta à sua realidade. A resposta não está em eliminar os testes E2E, mas em utilizá-los com parcimônia e inteligência, como parte de uma estratégia de teste bem equilibrada.

Este artigo foi bastante extenso e profundo. Em futuro post, vamos concluir a discussão abordando o seguinte tema Testes de Contrato vs. Testes End-to-End: Eficiência e Performance. Até logo! 👨🏻‍💻

1. "Parcimônia" é um termo que se refere ao uso moderado e econômico de recursos, tempo ou palavras. Em um sentido mais amplo, representa a ideia de fazer algo de maneira simples, sem excessos, utilizando o mínimo necessário para alcançar um objetivo de forma eficiente e eficaz.

---

2. Não vou comentar nesse artigo estratégias para lidar com Flaky Tests em testes E2E, isso ficará para uma próxima oportunidade.

---

3. Isso cria uma cultura de aversão ao risco, onde a inovação e a melhoria contínua são sufocadas.