DS & II

Capítulo 11 - Qualidade e Testes

Leitura de 5 min

🚀 Capítulo 11: Qualidade e Testes de Software (Tema: Matrix)

NOTE

Este capítulo utiliza a temática de Matrix para explicar os Testes de Software. Teste a realidade em todos os níveis para garantir que os humanos não percebam nenhuma falha na simulação!

1. 🎯 Objetivo da Aula

Compreender a importância dos Testes de Software, conhecendo a Pirâmide de Testes e os diferentes níveis: Testes Unitários, de Integração e de Ponta a Ponta (E2E).

2. 🏢 O Cenário Prático (Seu Desafio)

O Arquiteto da Matrix não pode simplesmente ligar o sistema e esperar que tudo funcione. Se houver um bug na simulação e a maçã cair para cima em vez de cair para baixo, os humanos vão perceber que estão em um mundo falso e a Matrix entrará em colapso! Para garantir a perfeição, o Arquiteto precisa testar o sistema em vários níveis de detalhe.

No desenvolvimento de software, nós fazemos exatamente a mesma coisa. Não confiamos na sorte! Criamos programas que testam os nossos próprios programas. Seu desafio é garantir que a Matrix não tenha falhas!

🧠 Fundamentos: A Teoria Traduzida

Para organizar os testes, usamos o conceito da Pirâmide de Testes. Ela nos diz a quantidade ideal de cada tipo de teste que devemos ter:

📐 A Pirâmide de Testes:

1. Testes Unitários (A Base da Pirâmide):

Testam a menor parte possível do código isoladamente (geralmente uma única função ou método).

  • Exemplo na Matrix: Testar se a função matemática que calcula a gravidade funciona corretamente.
  • Características: São super rápidos de rodar e muito baratos de criar. Devemos ter muitos desses!

2. Testes de Integração (O Meio da Pirâmide):

Testam se duas ou mais partes do sistema funcionam bem quando juntas.

  • Exemplo na Matrix: Testar se a maçã (objeto) reage corretamente à gravidade (sistema de física).
  • Características: Um pouco mais lentos e complexos. Devemos ter uma quantidade moderada.

3. Testes de Ponta a Ponta / E2E (O Topo da Pirâmide):

Testam o sistema inteiro simulando o comportamento de um usuário real do início ao fim.

  • Exemplo na Matrix: Um robô simulando um humano entra na Matrix, compra um pão na padaria, come e vê se tudo pareceu real.
  • Características: São muito lentos e caros de manter. Devemos ter poucos desses, apenas para os caminhos mais importantes do sistema.

4. 📖 Exemplo Guiado: O Teste Automatizado

Imagine que você escreveu uma função em C++ que soma dois números:

int somar(int a, int b) { return a + b; }

Um Teste Unitário para essa função seria outro arquivo de código que faz isso:

if (somar(2, 3) == 5) {
    cout << "Teste Passou! (Verde)";
} else {
    cout << "Teste Falhou! (Vermelho)";
}

Se amanhã você mudar a função de soma e estragar o cálculo, o teste vai gritar “Vermelho” e você saberá na hora que errou!

5. 🛠️ Prática Obrigatória 1: Qual o tipo de teste?

Identifique se a situação descreve um teste Unitário, de Integração ou de Ponta a Ponta (E2E):

  1. Um robô de testes abre o navegador, entra no site do banco, digita o usuário e senha, clica em “Entrar” e verifica se a tela de saldo apareceu.
  2. Um teste verifica se a função calcular_desconto() dá o resultado correto de para uma compra de com cupom de .
  3. Um teste verifica se o sistema consegue salvar um novo usuário no banco de dados real e depois buscá-lo de volta.

6. 🛠️ Prática Obrigatória 2: Por que não testar tudo no final?

Por que devemos ter MUITOS testes unitários e POUCOS testes de ponta a ponta (E2E) na nossa pirâmide? O que acontece com o tempo de espera da equipe se tivermos 10.000 testes E2E?

7. 📤 Instruções de Entrega (GitHub Desktop + Microsoft Teams)

  1. Faça o Commit: No GitHub Desktop, digite a mensagem (ex: Finaliza Capítulo 11 EngSoftware) e clique em Commit to main.
  2. Envie para a Nuvem (Push): Clique em Push origin.

8. 📂 Estrutura de Pastas

extra_engenharia_de_software/
├── capitulos/
│   ├── capitulo_11_testes.md
│   └── codigos/
│       └── cap11/
│           └── teste_gravidade.cpp

💡 Checkpoint de Lógica

Testes não servem para provar que o código não tem erros. Servem para provar que o código faz o que deveria fazer nas situações que nós imaginamos!

10. 🔥 Desafio de Fixação

Pesquise o que significa o termo Bug e qual a origem histórica dessa palavra na computação.

🔑 Gabarito de Código/Fórmulas

Gabarito da Prática 1:

  1. Ponta a Ponta (E2E) (Simula o usuário real no navegador).
  2. Unitário (Testa apenas uma função isolada).
  3. Integração (Testa a comunicação entre o código e o banco de dados). Gabarito da Prática 2:
  4. Porque os testes E2E são muito lentos (abrem navegador, clicam, esperam carregar). Se tivéssemos 10.000 testes E2E, a equipe teria que esperar horas ou dias para saber se uma pequena alteração no código estragou o sistema. Os testes unitários rodam milhares em poucos segundos!

← Capitulo Anterior | Proximo Capitulo →

Visão de gráfico

Backlinks