Módulo 2: Tipos e níveis de teste

1. Unitário (unit)

Testa a menor peça isolada: uma função, uma classe. Sem banco, sem rede, sem tela. Roda em milissegundos. Normalmente escrito por quem desenvolve.
Exemplo: a função calcular_desconto(100, "VIP") devolve 85?

2. Integração

Testa duas ou mais peças conversando: o código e o banco, o serviço e a API de pagamento, dois microsserviços. É aqui que aparecem os defeitos que o teste unitário nunca acha: contrato trocado, campo com nome diferente, transação que não fecha.
Exemplo: ao salvar um pedido, ele realmente aparece na tabela pedidos com o valor_total certo?

3. Sistema

O sistema inteiro montado, testado de ponta a ponta, como um usuário usaria. É o nível onde mais gente pensa quando ouve "teste".
Exemplo: entrar no site, buscar um produto, adicionar ao carrinho, pagar e receber o e-mail de confirmação.

4. Aceite (UAT)

Confirma que o que foi construído atende a necessidade de quem pediu. Quem conduz muitas vezes é a área de negócio, não o time técnico. Aqui a pergunta é de validação (Módulo 1), não de verificação.
Exemplo: o time comercial consegue fechar uma venda de ponta a ponta com o novo fluxo, do jeito que trabalha?

Funcional: o sistema faz o que deveria fazer? É a maior parte do trabalho e o foco das trilhas de SQL, API e pytest deste curso.

Não-funcional: como ele faz. Os principais:

Tipo	Pergunta	Exemplo de defeito
Performance / carga	aguenta quanta gente, e em quanto tempo responde?	a busca leva 8s quando há 200 usuários simultâneos
Segurança	dá pra acessar o que não deveria?	trocando o id na URL, vejo o pedido de outro cliente
Usabilidade	a pessoa consegue usar sem sofrer?	a mensagem de erro não diz qual campo está errado
Compatibilidade	funciona nos navegadores e aparelhos que importam?	o botão de pagar fica fora da tela no celular
Acessibilidade	funciona pra quem usa leitor de tela, teclado, alto contraste?	o campo não tem rótulo associado; o leitor de tela lê "editar texto"
Confiabilidade	se recupera quando algo cai?	o pedido some se a API de pagamento demorar

Na prática: defeito não-funcional costuma ser mais caro e mais difícil de corrigir tarde, porque mexe em arquitetura. É mais um motivo pra perguntar sobre eles cedo: "quantos usuários simultâneos a gente espera?" é pergunta de refinamento, não de véspera de entrega.

• Caixa-preta: você testa pela entrada e pela saída, sem olhar o código. É o que o Módulo 3 ensina (partição de equivalência, valor limite, tabela de decisão). Serve pra qualquer nível.
• Caixa-branca: você usa o código como guia: quais ramos do if foram executados, quais linhas nunca rodaram. É o mundo da cobertura de código.
• Caixa-cinza: o meio do caminho, e o que mais se parece com o trabalho real de QA: você não escreveu o código, mas sabe que existe um banco por trás e vai conferir lá o que a tela não mostra. É exatamente o que você faz nas trilhas de SQL e de API deste curso.

Cobertura de código alta não significa bem testado: dá pra executar 100% das linhas sem verificar nenhum resultado. Cobertura mede o que foi executado, não o que foi verificado.

Nome	O que é	Quando roda
Smoke	um punhado de casos que provam que o básico está de pé (login abre, home carrega)	logo depois de subir uma versão, antes de gastar tempo com o resto
Regressão	rodar de novo o que já funcionava, pra ver se a mudança quebrou algo	a cada entrega, é o principal candidato a ser automatizado
Reteste / confirmação	testar de novo só o bug corrigido, seguindo os passos do relatório	quando um defeito volta como "resolvido"
Sanity	checagem rápida e focada numa área específica que acabou de mudar	correção pontual, sem tempo pra regressão completa

Reteste ≠ regressão. Reteste confirma que aquele bug morreu. Regressão confirma que a correção não matou outra coisa. Os dois são necessários, e é comum ver time fazer só o primeiro.

            /\            poucos, lentos, caros de manter
           /  \           E2E / interface — o fluxo inteiro pelo navegador
          /____\
         /      \         alguns, médios
        /        \        INTEGRAÇÃO — código + banco, serviço + API
       /__________\
      /            \      muitos, rápidos, baratos
     /              \     UNITÁRIO — funções isoladas, milissegundos
    /________________\

A ideia: quanto mais alto, mais caro e mais frágil o teste. Então concentre volume embaixo e use o topo com parcimônia, só pros fluxos que realmente importam (o do dinheiro, normalmente).

O anti-padrão é a casquinha de sorvete, pirâmide invertida: quase nada de unitário, muito teste de interface, e uma bola gigante de teste manual em cima. O sintoma é conhecido: a suíte demora 2 horas, falha sozinha metade das vezes, e ninguém confia no vermelho.

Automação não é sempre melhor. Ela troca tempo agora por tempo depois, e cobra manutenção. Vale quando:

• o teste vai rodar muitas vezes (regressão, a cada entrega);
• o resultado é objetivo (dá pra escrever um assert);
• o cenário é estável: automatizar tela que muda toda semana é jogar trabalho fora;
• fazer na mão é lento ou chato o bastante pra você acabar pulando.

E não vale quando o julgamento é humano: "essa tela está confusa?", "esse texto soa agressivo?", "o fluxo faz sentido?". Isso é trabalho de pessoa, e é onde o teste exploratório (Módulo 4) brilha.