DEV Community: Stephanto

Pirâmide de Testes: Do Unitário ao E2E - Introdução

Stephanto — Mon, 02 Jun 2025 21:44:35 +0000

Olá, comunidade dev! 👋 Se você busca desenvolver software com mais qualidade e confiança, entender a Pirâmide de Testes é fundamental. Popularizada por Mike Cohn, essa abordagem nos ajuda a organizar e priorizar os diferentes tipos de testes em nossos projetos.

Neste artigo, vamos mergulhar nas suas camadas – Unitários, Integração e End-to-End (E2E) – e desvendar o valor e o custo de cada uma. Preparados? 🚀

As Camadas da Pirâmide: Uma Visão Geral

A pirâmide é visualmente dividida em três camadas principais, cada uma com um papel específico e diferentes trade-offs:

🧱 Testes Unitários: A base sólida.
🔗 Testes de Integração: A conexão entre as partes.
🎯 Testes End-to-End (E2E): A validação da experiência completa.

Vamos explorar cada uma delas.

Testes End-to-End (E2E): Validando a Experiência do Usuário 🎯

No topo da pirâmide, os testes E2E simulam a jornada completa de um usuário real interagindo com sua aplicação. Pense em um teste de cadastro: o script abriria o site, preencheria os campos, submeteria o formulário e verificaria o resultado, passando pelo frontend, backend, banco de dados e qualquer outro serviço envolvido.

Valor do E2E:

Máximo para o Negócio: Garante que a funcionalidade crítica está operando como esperado do início ao fim, sob a perspectiva do usuário. ✅
Alta Confiança: Um conjunto de testes E2E bem-sucedido transmite grande confiança sobre a saúde geral da aplicação.

Custo do E2E:

Altíssimo: São os testes mais caros para desenvolver, manter e executar. 💸
Depuração Complexa: Identificar a causa raiz de uma falha pode ser demorado, já que muitos componentes estão envolvidos.
Ambiente Exigente: Requerem um ambiente de testes o mais fiel possível ao de produção, o que pode ser custoso e complexo de configurar.

Testes Unitários: A Fundação Sólida 🧱

Na base da pirâmide, os testes unitários focam na menor unidade de código isolável: uma função, um método ou uma classe pequena. O objetivo é simples: para uma entrada X, esperamos uma saída Y. Testamos diversos cenários, incluindo caminhos felizes e casos de exceção.

### Mocks ao Resgate!

Um erro comum é achar que testes unitários precisam acessar o banco de dados ou outros serviços externos. Pelo contrário! Para garantir isolamento e rapidez, usamos mocks (objetos simulados) para representar essas dependências.

Custo dos Unitários:

Baixíssimo: São baratos para escrever, executar e manter. ⚡️
Feedback Rápido: Executam em milissegundos, fornecendo feedback quase instantâneo aos desenvolvedores.
Depuração Fácil: Quando um teste unitário falha, o problema geralmente está contido na pequena unidade testada.

Valor dos Unitários:

Menor Valor Isolado (para o Negócio): Sozinhos, não garantem que a aplicação inteira funcione. Muitas unidades funcionando perfeitamente em isolamento podem falhar ao serem integradas. 🧩
Base Crucial para a Qualidade: Apesar disso, são a fundação! Ajudam a garantir que cada "tijolo" da sua aplicação é confiável.
Guia de Design: Incentivam um bom design de código (baixo acoplamento, alta coesão) e revelam problemas como falta de abstração ou injeção de dependência inadequada.
Documentação Viva: Descrevem como cada unidade de código deve se comportar.
Grande Quantidade: São os testes mais numerosos em uma codebase saudável.

Testes de Integração: Conectando os Pontos 🔗

Localizados no meio da pirâmide, os testes de integração verificam se diferentes unidades ou componentes do sistema se comunicam e colaboram corretamente. Se os testes unitários garantem que os tijolos são bons, os de integração garantem que eles se encaixam.

Aqui, pode ser válido interagir com um banco de dados real (geralmente em uma instância de teste, de menor escala) ou outros serviços externos para validar essa comunicação.

Valor da Integração:

Médio: Fornecem uma boa visão para os desenvolvedores sobre como diferentes partes da aplicação interagem e como os recursos são utilizados.
Confiança na Colaboração: Aumentam a confiança de que os módulos principais funcionam bem juntos.
Indicador de Saúde: Embora não representem a experiência final do usuário, dão um bom panorama do estado da aplicação.

Custo da Integração:

Médio: São mais caros e lentos que os testes unitários, pois envolvem múltiplos componentes.
Depuração Moderada: Identificar falhas pode ser mais complexo que nos testes unitários, mas geralmente mais simples que nos E2E.
Recursos: Podem exigir mais recursos de setup (ex: um banco de dados de teste) do que os unitários.

Por Que o Formato de Pirâmide? 🔺

O formato visual da pirâmide não é um acaso. Ele ilustra a proporção ideal de cada tipo de teste em um sistema saudável e com manutenção sustentável:

Base Larga (Muitos Testes Unitários): São rápidos, baratos e isolam falhas eficientemente. Constituem a maior parte da sua suíte de testes.
Meio (Menos Testes de Integração): Verificam as interações chave sem o custo dos E2E.
Topo Estreito (Poucos Testes E2E): Cobrem os fluxos críticos do usuário, mas são usados com moderação devido ao seu alto custo.

Seguir essa proporção ajuda a obter feedback rápido (a maioria dos testes são rápidos), custos de manutenção controlados e uma cobertura de risco eficaz.

Pontos de Atenção e Nuances 📝

Contexto é Rei: Os exemplos e proporções são um guia, não uma regra absoluta. Adapte a estratégia ao seu produto e contexto. Um teste E2E para uma API é diferente de um para uma aplicação web full-stack.
Integração no Frontend: Testes de integração não são exclusivos do backend! No frontend, eles podem verificar a interação entre componentes da UI, por exemplo.
Estratégia Balanceada: O objetivo final é ter uma estratégia de testes balanceada, que maximize a confiança e minimize os custos e o tempo de feedback. ⚖️

Concluindo...

A Pirâmide de Testes é um modelo poderoso para guiar sua estratégia de testes, ajudando a construir aplicações mais robustas, confiáveis e fáceis de manter. Lembre-se que testes são um investimento na qualidade e sustentabilidade do seu software!

E você, como aplica a Pirâmide de Testes nos seus projetos? Quais são seus maiores desafios ou aprendizados? Compartilhe nos comentários abaixo! 👇

Entendendo a Replicação de Banco de Dados: Uma Chave para Sistemas Robustos

Stephanto — Wed, 21 May 2025 19:50:04 +0000

Olá a todos! Estou aqui novamente para compartilhar mais do que aprendi esta semana, especificamente sobre o tema da replicação de dados. Este artigo fornecerá uma explicação resumida do que é e quais são os seus tipos. Vamos lá!

Por Que a Replicação de Dados é Importante?

Para entender a importância da replicação de dados, considere este cenário: Imagine que este é um servidor hospedado na minha casa. Se eu acidentalmente derramar café em cima do servidor/DB, o que acontece? Já era.

Temos aqui um "Single point of failure".

Outro ponto é que usuários de países diferentes têm tempos de resposta diferentes. Dependendo da localização, demora um tempo considerável para obter resposta da aplicação, o que pode prejudicar a experiência do usuário.

Então, a replicação pode servir para, caso algum servidor deixe de funcionar, aumentar a disponibilidade e diminuir a latência para diferentes localidades. Adicionamos mais DBs para poder garantir essas melhorias.

Porém, não sei se vocês notaram, mas surge um novo problema: Temos 3 bancos de dados em 3 lugares diferentes. Como garantir e manter a sincronização entre os 3 bancos de dados?

Abordagens para Consistência de Dados

Ao lidar com múltiplos bancos de dados, garantir a consistência dos dados é crucial. Existem duas abordagens principais:

1. Replicação Síncrona

A primeira abordagem é a Síncrona. Ela garante o dado mais recente (tendo uma consistência forte) através de fazer com que o usuário aguarde, se necessário, todo o processo de replicação para obter a resposta dele. O problema dessa abordagem é que ela gera uma certa lentidão.
![Sincrona]https://pbs.twimg.com/media/GpI_d8sWsAAYR5J?format=jpg&name=4096x4096)

2. Replicação Assíncrona

A outra abordagem é a Assíncrona. Com ela, o usuário não precisa esperar todo o processo de replicação (pois ele é feito em background), o que torna o acesso ao dado mais rápido. Seu problema é que não garante que a consistência seja 100%, e sim a chamada "consistência eventual".

Métodos de Replicação

Agora que vocês sabem as abordagens, vamos para os métodos de replicação. Vou apresentar 3:

Single-leader replication
Multi-leader replication
Leaderless replication

1. Single-Leader Replication

No Single-leader replication, apenas um banco recebe os writes e replica para os outros que apenas recebem reads.

Prós: É bom pois não tem conflitos.
Contras: Porém, tem um Throughput baixo e possui Single point of failure pois só um escreve.
Caso de Uso: É comum de ser usado em aplicações financeiras.

2. Multi-Leader Replication

Já o Multi-leader replication, a replicação de dados ocorre entre os DBs, ou seja, todos são líderes.

Prós: Possui um alto throughput para escritas.
Contras: O que pode gerar conflitos nas escritas.
Caso de Uso: É usado para grandes áreas geográficas.

3. Leaderless Replication

Por fim, o Leaderless replication funciona na forma de "Quorum" para lidas e escritas. Para simplificar, veja a imagem abaixo: Temos 4 nós, se um user quiser ler/escrever, será lido um pouco a mais da metade do número de nós para assim ter a resposta.

Prós: Isso é feito para garantir a consistência, o que gera uma alta disponibilidade.
Contras: Porém, acaba causando conflitos de escrita e gera latência na leitura.
Caso de Uso: É usado em sistemas que priorizam alta disponibilidade e tolerância a falhas, como sistemas de mensagens.

Conclusão

Bom, é isso. Espero que minha explicação tenha sido clara. Caso queiram, eu posso aprofundar mais em consistência e como lidar com conflitos de escrita. Fiquem livres para adicionar o que acharem relevante!

Obrigado por lerem até aqui!

Recomendo se aprofundarem em cada um deles, dei apenas uma visão geral e superficial para compreensão geral. Alguns materiais para leitura que dão uma complementada legal:

COMO ESCALAR UM SISTEMA PARA 1 MILHÃO DE USUÁRIOS?

Stephanto — Wed, 23 Apr 2025 15:05:18 +0000

Escalar um sistema para suportar milhões de usuários é um desafio significativo. A complexidade aumenta com o aumento da carga de dados e usuários, demandando uma arquitetura robusta. Neste artigo, exploraremos como escalar um sistema para lidar com 1 milhão de usuários, utilizando boas práticas e abordagens como balanceamento de carga, caches, e sharding.

O fluxo comum de um usuário ao acessar um site é: Acessar o o site pela URL, o DNS traduzir o endereço, a requisição chegar no servidor e devolver o conteúdo para o usuário

Se começarmos a ter usuários acessando nosso site e quisermos guardar seus registros e/ou ter um backend que queremos armazenar dados, temos que ter um database que vai salvar e resgatar esses dados

Porém, como temos apenas 1 servidor, a medida que o número de usuários aumenta, pode gerar delay e timeout para alguns usuários, para isso adicionamos o loadbalancer que vai cuidar de encaminhar os usuários para os diferente servidores para não sobrecarregar

Agora, como teremos mais de um banco de dados (por conta do aumento de servidores), precisamos garantir a consistência dos dados. Podemos utilizar o método de Master/Slave, que somente 1 database recebe as escritas, replica para os outros e eles apenas leem os registros

Vamos dar uma olhada em como ficou nosso sistema até agora então, está bom mas ainda podemos melhorar bastante a performance

Podemos adicionar um cache para dados frequentemente acessados. Assim, melhora a velocidade e poupa acessos ao banco de dados pela memória cache ser mais rápida

Podemos também adicionar um CDN. Um CDN é um servidor estrategicamente localizado em um lugar que seja mais perto do cliente, funciona semelhante a um cache

Com essas adições nosso sistema esta desta forma até agora:

Ok, mas como escalamos ainda mais? Podemos mover uma parte do sistema para stateless, por exemplo, tirar o estado do usuário do servidor e adicionar em um NoSQL. No exemplo abaixo é como seria o acesso do usuário sem stateless, sua sessão e foto de perfil ficam apenas em 1 server

Já com stateless, adicionamos um shared storage para adicionar a sessão e a foto de perfil do usuário, para manter uma boa experiência de usuário (se o loadbalancer jogar ele pra outro servidor, ele não ser deslogado ou coisa do tipo)

Com essa adição, nosso sistema está ficando cada vez mais bonito e escalável

Ta bom, mas e se seu sistema quer internacionalizar? Para isso, vamos ter outro datacenter em outro país, e com isso, adicionamos um outro loadbalancer mas com algoritmo de georoute nele

Uma boa prática (algumas vezes) é desacoplar alguma função frequente que ser servidor faz para aumentar o desempenho e diminuir o overload em um macro-serviço. Exemplo, podemos fazer um sistema separado para processamento de imagens no nosso servidor usando sistema de filas. Com esse sistema de filas, caso algum servidor caia, não é perdido a requisição, além de, como dito anteriormente, diminuir o overload

Com isso, nosso sistema fica dessa forma:

Por fim, o que podemos fazer é diminuir a sobrecarga do banco de dados. As bases de dados estão apenas com redundância até agora, com os mesmos tipos de dados em todos eles. Com isso, podemos usar um método chamado sharding.
Sharding é, de forma simplifcada, usar um algoritmo para dividir a alocação de um registro em bases de dados diferentes. O exemplo abaixo vai elucidar melhor.
Vou pegar o id do usuário e fazer módulo 4, o resultado vai fazer com que ele seja salvo em um DB especifico

Essa é uma visão de como ficaria cada um dos bancos de dados após o sharding:

Agora juntando tudo isso que temos, voltamos para a imagem inicial do artigo. Vocês tem um sistema escalável para bem mais que 1 milhão de usuários!

Espero que tenham compreendido de forma simples o funcionamento disso. Novamente, aconselho aprofundar no assunto!

Obrigado por ler até aqui!