O que são testes e por que testar

Resumo em uma linha

Um teste automatizado é um programa que roda o seu programa e verifica se o resultado bate com o esperado — mas a razão de existir dele não é caçar bug, é te dar velocidade, documentação viva, confiança pra fazer deploy e pressão por bom design.

Comece pela definição mais crua possível. Um teste automatizado é código. Código que chama o seu código, observa o que sai e compara com o que deveria sair. Se bate, passa. Se não bate, falha e te avisa. Só isso.

def soma(a, b):
    return a + b
 
def test_soma():
    assert soma(2, 3) == 5   # arrange + act + assert, tudo aqui

Esse é o átomo. Um assert que confronta o real com o esperado. Tudo no mundo dos testes — frameworks, mocks, pirâmides, TDD — é elaboração em cima desse átomo.

Mas aqui está a pergunta que separa quem entende de quem decora: se testar fosse só “achar bug”, por que times maduros escrevem testes ANTES de o bug existir? Por que escrevem testes pra código que já funciona? A resposta é que pegar bug é o efeito mais óbvio dos testes — e o menos importante.

Testar não é caçar bug (essa é a parte rasa)

Pense num teste manual. Você roda o programa, clica nos botões, olha a tela. Funciona? Beleza. Esse é o jeito que todo mundo testa no começo — e funciona, até o programa crescer.

O problema do teste manual não é que ele falha em achar bugs. É que ele não escala no tempo. Você corrige um campo no formulário e precisa reclicar os outros quarenta pra ter certeza de que não quebrou nada. Ninguém faz isso. Então você confere só o que mexeu, reza, e descobre o estrago em produção.

O teste automatizado resolve isso com uma propriedade boba e poderosa: ele é barato de repetir. Escrever custa caro uma vez; rodar custa quase nada infinitas vezes. É essa assimetria que muda tudo.

Então por que escrevemos testes de verdade?

Não pra “verificar que funciona hoje”. É pra continuar sabendo que funciona depois de mil mudanças. O valor do teste não está no momento em que você escreve — está em cada git push futuro em que ele roda sozinho e te diz “pode seguir”.

As quatro funções estratégicas

Aqui mora a tese da nota. Testes existem por quatro razões, e nenhuma delas é “encontrar defeitos” diretamente. Vamos ver o mapa antes do detalhe.

flowchart TD
    T["Suíte de testes automatizados"] --> V["1 · Velocidade<br/>refatorar sem medo"]
    T --> D["2 · Documentação<br/>spec executável"]
    T --> C["3 · Confiança<br/>deploy contínuo"]
    T --> B["4 · Bom design<br/>pressão sobre acoplamento"]
    V --> R["o time muda código<br/>mais rápido"]
    D --> R
    C --> R
    B --> R
    R["Software que evolui<br/>sem apodrecer"]

Leitura do diagrama: a suíte é uma só, mas paga em quatro moedas diferentes. Velocidade, documentação, confiança e design são caminhos distintos que desembocam no mesmo lugar — software que continua mole, que aceita mudança sem virar pântano. Note que “achar bug” não aparece como função: ele é um sub-produto da função 1 (a suíte pega a regressão no instante em que você quebra algo).

1 · Velocidade — o paradoxo da rede de segurança

Esta é a função mais contra-intuitiva, então é a que mais cai em entrevista. A frase que todo júnior fala: “testes deixam tudo mais lento, tenho que escrever o dobro de código”. E está certo — no curtíssimo prazo.

O paradoxo: testes parecem desacelerar e na verdade aceleram. Por quê? Porque a coisa mais cara em software não é digitar código novo. É ter medo de mexer no código velho.

flowchart LR
    M["Mudança<br/>(refactor, feature)"] --> S["Suíte roda"]
    S -->|verde| OK["Confiança<br/>segue em frente"]
    S -->|vermelho| FIX["Pega a regressão<br/>na hora"]
    FIX --> M
    OK --> SHIP["Deploy"]

    M2["Mudança<br/>sem suíte"] --> FEAR["Medo<br/>"]
    FEAR --> SLOW["Não mexe / mexe devagar /<br/>quebra em produção"]

Leitura do diagrama: no trilho de cima, a suíte é uma rede de segurança — você muda, ela confere, e você sabe em segundos se quebrou algo. No trilho de baixo, sem suíte, cada mudança carrega medo, e medo é o freio mais caro que existe num codebase. Kent Beck nomeia isso direto: o objetivo do TDD é eliminar o medo do programador. Trabalhar com medo é trabalhar devagar.

A rede de segurança em uma imagem

Um trapezista voa solto porque tem rede embaixo. Tire a rede e ele vai parar de soltar das mãos — vai se agarrar à barra. Código sem testes é trapezista sem rede: o time para de ousar refatorar, e o design congela no estado em que estava no dia em que o medo começou.

É por isso que testes habilitam refatoração. Refatorar é mudar a forma do código sem mudar o comportamento. Como você garante que o comportamento não mudou? A suíte verde. Sem ela, “refatorar” vira “reescrever e torcer”.

Isso conecta direto com a entropia do software: todo sistema tende a apodrecer conforme é tocado por mãos diferentes ao longo de anos. Testes são o que segura a maré — veja Manutenção e evolução pra entender por que a manutenção, e não a escrita inicial, é onde mora o custo real do software.

2 · Documentação — a spec que não mente

Todo README mente. Não por má fé: ele mente porque o código muda e a prosa não acompanha. Você lê “o endpoint retorna 200 com o usuário”, roda, e leva 404. A documentação descreveu uma versão do sistema que não existe mais.

Um teste não pode mentir sobre o comportamento atual. Se o teste afirma assert resposta.status == 200 e o código retorna 404, o teste falha. Documentação que falha quando está errada é documentação que se mantém honesta à força.

def test_saque_acima_do_saldo_e_recusado():
    conta = Conta(saldo=100)
    with pytest.raises(SaldoInsuficiente):
        conta.sacar(150)

Leia esse teste como uma frase: “sacar mais que o saldo é recusado com SaldoInsuficiente”. Isso é uma especificação executável. Um dev novo no time lê a suíte e aprende as regras de negócio sem precisar perguntar — e sem o risco de a regra estar desatualizada, porque se estivesse, a suíte estaria vermelha.

Spec executável tem um nome melhor que README

O melhor jeito de saber o que um método faz não é o comentário em cima dele. É o teste que descreve o que ele faz em cenários concretos. Por isso bons nomes de teste viram frases: deve_recusar_saque_acima_do_saldo. O conjunto de nomes da suíte é o sumário do comportamento do sistema.

3 · Confiança — sem suíte não existe deploy contínuo

Por que algumas empresas fazem deploy cinquenta vezes por dia e outras tremem pra subir uma vez por mês? A diferença raramente é ferramenta de CI. É confiança na suíte.

Entrega contínua é um pipeline: commit → testes → build → produção, sem mão humana clicando “aprovar”. Esse pipeline só pode existir se há um portão automático em que você confia o suficiente pra deixar ir pra produção sem revisão manual. Esse portão é a suíte de testes.

A confiança é frágil e some rápido

Basta a suíte deixar passar um bug feio em produção uma vez pra o time perder a fé nela — e voltar pro teste manual de tudo. Confiança em suíte é capital que se constrói devagar e se perde de uma vez. Testes que falham aleatoriamente (os flaky) são o ácido que corrói essa confiança: se metade das falhas é ruído, o time aprende a ignorar TODAS as falhas.

4 · Bom design — código difícil de testar é código mal desenhado

Esta função é a mais sutil e a mais valiosa. Quando você tenta escrever um teste e sofre — precisa subir um banco inteiro, mockar dez coisas, instanciar metade do sistema só pra testar uma função — o teste está te dando um diagnóstico de design, não um obstáculo.

Código fácil de testar é código com responsabilidades separadas e dependências que entram por fora (injetadas), em vez de serem criadas lá dentro. Isso não é coincidência: testabilidade e bom design são a mesma propriedade vista de ângulos diferentes.

O teste como crítico de arquitetura

Se pra testar a função calcular_frete você precisa de uma conexão de banco real, é porque ela está acoplada ao banco quando não devia. O teste doloroso está apontando o acoplamento. A dor não é do teste — é do design, e o teste só a tornou visível.

É aqui que SOLID entra como par natural dos testes. O DIP (Inversão de Dependência) — depender de abstrações e injetar as dependências concretas — é exatamente o que torna um objeto testável em isolamento: você passa um dublê no lugar da dependência real. Testes pressionam você a injetar dependências; injetar dependências é o coração do DIP. Quem pratica testes acaba praticando SOLID sem ter lido o acrônimo.

O custo é real — e mesmo assim vale

Seria desonesto pintar testes como grátis. Eles têm dois custos concretos:

• Custo de escrita: cada comportamento testado é código a mais pra digitar e pensar.
• Custo de manutenção: quando o comportamento legítimo muda, os testes daquele comportamento precisam mudar junto. Uma suíte mal desenhada faz cada refactor disparar dezenas de testes vermelhos por nada.

Esse segundo custo é o veneno silencioso. Testes acoplados a detalhes de implementação (em vez de comportamento) viram um lastro: quebram a cada mudança interna mesmo quando o comportamento externo está intacto. Vladimir Khorikov chama isso de falta de resistência a refatoração — uma das quatro qualidades de um bom teste (proteção contra regressão, resistência a refatoração, feedback rápido, manutenibilidade). Voltaremos a isso em 03 - Anatomia de um bom teste.

Se custa, por que vale?

Porque o custo de escrever e manter testes é pago UMA vez por comportamento, e a economia (refatorar sem medo, deploy sem tremer, onboarding sem perguntar) é colhida MIL vezes ao longo da vida do sistema. A conta só fecha porque software vive muito mais tempo na fase de manutenção do que na de escrita inicial.

A nuance sênior: nem todo código merece o mesmo nível de teste. Um script descartável que roda uma vez não precisa de suíte. Um motor de cálculo de juros que processa milhões de reais por dia precisa de muito teste. Saber onde gastar o orçamento de testes é estratégia — não dogma.

As duas faces dos testes em entrevista

Aqui está o mapa de todo o galho. Testes aparecem em entrevista de duas formas bem diferentes, e confundir as duas é o erro clássico do candidato.

flowchart TD
    Q["Pergunta sobre testes<br/>na entrevista"] --> E["FACE A · Estratégia<br/>(o que separa o sênior)"]
    Q --> T["FACE B · Técnica<br/>(escrever um bom teste)"]

    E --> E1["Qual tipo de teste usar?"]
    E --> E2["Quando e em que proporção?"]
    E --> E3["Por que vale o custo?"]
    E1 --> EP["[[02 - A pirâmide de testes e suas variações]]<br/>[[16 - Estratégia de testes em entrevista]]"]

    T --> T1["Estrutura AAA / Given-When-Then"]
    T --> T2["Teste legível, isolado, determinístico"]
    T --> T3["O ciclo Red-Green-Refactor"]
    T1 --> TP["[[03 - Anatomia de um bom teste]]<br/>[[04 - Testes unitários]]<br/>[[08 - TDD - o ciclo Red-Green-Refactor]]"]

Leitura do diagrama: a Face A (estratégia) é o que o entrevistador de sênior está sondando — ele quer ouvir você raciocinar sobre QUAIS testes escrever, em que proporção, e por quê, à luz de confiança × velocidade × custo. A Face B (técnica) é a habilidade de mão: escrever um teste limpo, isolado e legível. Júnior costuma só ter a Face B. O candidato que articula a Face A — “eu colocaria a maior parte do esforço em testes unitários do domínio, poucos de integração nas fronteiras, e pouquíssimos end-to-end nos fluxos críticos, porque…” — soa sênior na hora.

A frase que resume a senioridade

Escrever um teste é fácil. Desenhar uma estratégia de testes que equilibra confiança, velocidade e custo de manutenção é o que diferencia. Frameworks você aprende numa tarde; estratégia você defende numa entrevista.

Este galho cobre as duas faces. A técnica vem em 03 - Anatomia de um bom teste e 04 - Testes unitários; o ciclo de trabalho guiado por testes em 08 - TDD - o ciclo Red-Green-Refactor; a estratégia macro em 02 - A pirâmide de testes e suas variações e 16 - Estratégia de testes em entrevista. E, na ponta de linguagem, Testes em Java e Testes em JavaScript aterrissam tudo isso em ferramentas concretas.

Em entrevista

Frases prontas em inglês pra defender a importância dos testes sem soar dogmático:

• “Tests aren’t primarily about catching bugs — they’re a safety net that lets us refactor and ship without fear.”
• “A good test suite is executable documentation: unlike a README, it can’t drift out of date, because if it lied, it would fail.”
• “Continuous delivery only works if you trust your suite — the test suite is the automated gate that replaces manual sign-off.”
• “When a piece of code is hard to test, that’s usually a design smell pointing at tight coupling or hidden dependencies, not a problem with testing itself.”
• “Writing tests has a real cost to write and maintain, but it pays off because software spends far more of its life being changed than being written.”
• “I’d separate the strategy question — what to test and in what proportion — from the technique of writing a clean, isolated test; senior interviews usually probe the first.”
• “I treat flaky tests as a fire to put out fast, because they erode the team’s trust in the whole suite.”

Vocabulário

Português	English
teste automatizado	automated test
suíte de testes	test suite
spec / especificação executável	executable specification
rede de segurança	safety net
refatorar sem medo	refactor without fear
cobertura de testes	test coverage
regressão	regression
teste instável / não-determinístico	flaky test
dependência injetada	injected dependency
dublê de teste	test double
entrega contínua	continuous delivery
custo de manutenção	maintenance cost

Lastro

• Kent Beck, Test-Driven Development: By Example (Addison-Wesley, 2002) — testes como rede de segurança que elimina o medo de refatorar; “the tests are the teeth of the ratchet”.
• Vladimir Khorikov, Unit Testing Principles, Practices, and Patterns (Manning, 2020) — as quatro qualidades de um bom teste: proteção contra regressão, resistência a refatoração, feedback rápido e manutenibilidade.
• Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — código legado definido como “código sem testes”; testes como pré-condição pra mudar com segurança.

Veja também

• 02 - A pirâmide de testes e suas variações — a estratégia macro: quais tipos e em que proporção
• 03 - Anatomia de um bom teste — a técnica: o que faz um teste ser bom
• 04 - Testes unitários — o tijolo fundamental da pirâmide
• 08 - TDD - o ciclo Red-Green-Refactor — escrever o teste antes do código
• 16 - Estratégia de testes em entrevista — a Face A destrinchada
• Testes — índice do galho