Testes e qualidade de código

Por que escrever testes? O verdadeiro motivo para fazer isso mesmo sendo trabalhoso

"Quando vou conseguir escrever tudo isso...?" Até criar uma única funcionalidade já é corrido; quando pedem testes também, dá vontade de suspirar.

3 min de leitura
Imagem de capa de Por que escrever testes? O verdadeiro motivo para fazer isso mesmo sendo trabalhoso

“Quando vou conseguir escrever tudo isso…?” Até criar uma única funcionalidade já é corrido; quando pedem testes também, dá vontade de suspirar.

Indo direto ao ponto, o verdadeiro motivo para escrever testes é proteger o seu eu do futuro. Você investe 10 minutos a mais agora para evitar uma indisponibilidade de madrugada daqui a 3 meses.

Por que escrever testes?

O principal motivo é que corrigir código deixa de dar medo.

Código não é escrito uma vez e encerrado. Ele é alterado continuamente e recebe novas funcionalidades.

Sem testes, cada alteração de uma linha traz insegurança. “Se eu corrigir isso, outra parte não vai quebrar?”

Com testes, uma única execução confirma a alteração. Verde traz alívio; vermelho mostra imediatamente o que quebrou.

Corrija, execute uma vez e, se não ficar verde, descubra a causa imediatamente
Corrija, execute uma vez e, se não ficar verde, descubra a causa imediatamente

Isso se chama teste de regressão: ele detecta quando algo que funcionava antes quebra novamente.


O verdadeiro motivo para escrever testes mesmo sendo trabalhoso

Sinceramente, testes parecem um prejuízo no começo. Afinal, eles não aumentam nenhuma funcionalidade visível.

Mas a história muda conforme o projeto cresce.

Quando há 30 ou 50 funcionalidades, é impossível verificar tudo manualmente. Não dá para clicar em tudo cada vez que você altera algo.

Com testes, uma única linha de comando valida dezenas de casos em poucos segundos.

O segundo motivo é que o código de teste se torna documentação.

Ao ler testes bem escritos, você entende de imediato quais resultados uma função produz para determinadas entradas.

Comentários podem mentir quando ficam desatualizados, mas testes são executados e, por isso, não conseguem mentir.

Vamos ver um exemplo simples: o teste de uma função que calcula um desconto.

// 1uma compra de dez mil wones 10% de desconto → 9deve resultar em mil wones
@Test func aplicar a_10porcentagem de_desconto() {
    let result = applyDiscount(10000, rate: 0.1)
    #expect(result == 9000)
}

Só de olhar esse teste, já dá para entender o que applyDiscount faz.

Só vivendo para entender o alívio do momento em que aparece PASS no terminal
Só vivendo para entender o alívio do momento em que aparece PASS no terminal

Como começar a escrever testes?

Tentar testar tudo desde o início vai deixar você exausto e fazer você desistir.

Recomendo começar assim.

  1. Comece pela lógica essencial cujo erro causaria um grande problema, como cálculo de valores e login
  2. Funções com muitas ramificações condicionais que causam confusão
  3. Pontos onde já ocorreu um bug, para evitar que ele volte

Já o código simples de tela e as partes que mudam com frequência podem ficar para depois.

O objetivo não é testar tudo a 100%; o essencial é avaliar o benefício em relação ao custo.

Comecei adicionando testes aos poucos, seguindo estas três prioridades
Comecei adicionando testes aos poucos, seguindo estas três prioridades

Perguntas frequentes

P. Escrever testes não deixa o desenvolvimento mais lento?

R. No começo, sim. Mas, a partir da metade do projeto, ele fica mais rápido, porque o tempo para encontrar e corrigir bugs diminui bastante.

P. Qual é uma boa porcentagem de cobertura de testes?

R. Não é preciso ficar obcecado pelo número. 70–80% é suficiente; mais importante é cobrir a lógica essencial.


Código de teste não é para exibir habilidade, mas uma rede de segurança para o seu eu futuro e seus colegas.

Adicione hoje apenas um teste a uma função. Depois de sentir o alívio daquela pequena luz verde, você entenderá na prática por que todo mundo recomenda escrever testes.

Continue lendo