DS & II

Capítulo 12 - TDD

Leitura de 4 min

🚀 Capítulo 12: TDD (Test Driven Development) (Tema: Minority Report)

NOTE

Este capítulo utiliza a temática de Minority Report para explicar o TDD. Preveja os erros antes que eles aconteçam escrevendo o teste antes do código!

1. 🎯 Objetivo da Aula

Compreender o conceito de TDD (Test Driven Development - Desenvolvimento Guiado por Testes), entendendo o ciclo Red-Green-Refactor e as vantagens de se trabalhar dessa forma.

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

No filme Minority Report, a polícia usa seres especiais chamados “Precognitivos” que conseguem prever um crime antes que ele aconteça. A polícia vai até o local e impede o criminoso antes que ele faça algo errado.

No desenvolvimento de software tradicional, nós escrevemos o código e depois testamos para ver se tem erros (reagimos ao crime). No TDD, nós agimos como a polícia do filme! Nós escrevemos o teste antes de escrever o código da funcionalidade. O teste serve como a “previsão” de como o código deve funcionar. Se o código não funcionar como o teste previu, o teste falha! Seu desafio é prever o comportamento do seu código!

🧠 Fundamentos: A Teoria Traduzida

O TDD inverta a ordem das coisas. Em vez de Programar Testar, nós fazemos: Testar Programar.

🔄 O Ciclo Red-Green-Refactor:

O TDD funciona em um ciclo infinito de 3 passos:

  1. 🔴 RED (Vermelho):
    • Você escreve um teste para uma função que ainda não existe.
    • Você roda o teste e ele falha (fica vermelho) porque o código ainda não foi escrito. Isso prova que o teste é válido e está procurando algo real.
  2. 🟢 GREEN (Verde):
    • Você escreve o código mais simples e rápido possível apenas para fazer o teste passar.
    • Você roda o teste e ele passa (fica verde).
  3. 🔵 REFACTOR (Refatorar):
    • Agora que o código funciona e está protegido pelo teste, você limpa a bagunça! Melhora os nomes das variáveis, remove duplicidades e aplica o Clean Code.
    • Você roda o teste de novo para garantir que a sua limpeza não quebrou nada!

4. 📖 Exemplo Guiado: O Ciclo na Prática

Imagine que queremos criar uma função que diz se uma pessoa pode votar (idade ).

  1. RED: Escrevo o teste: assert(pode_votar(16) == true). O teste dá erro porque a função pode_votar nem existe.
  2. GREEN: Escrevo o código mais bobo possível: bool pode_votar(int idade) { return true; }. O teste passa! (Ficou verde).
  3. REFACTOR: Agora eu arrumo o código para a lógica real: bool pode_votar(int idade) { return idade >= 16; }. O teste continua passando!

5. 🛠️ Prática Obrigatória 1: Em qual fase estamos?

Identifique em qual fase do ciclo TDD (Red, Green ou Refactor) a equipe está em cada situação:

  1. O programador acabou de escrever um teste e a tela do computador ficou vermelha acusando que a função ainda não foi implementada.
  2. O programador está mudando o nome de uma variável de x para limite_de_tentativas após o teste já ter passado com sucesso.
  3. O programador escreveu um código provisório bem simples apenas para fazer a barra de progresso do teste ficar verde.

6. 🛠️ Prática Obrigatória 2: A Vantagem do TDD

Muitos programadores dizem que o TDD faz a equipe perder tempo, porque você precisa escrever o dobro de código (o teste e o programa).

  1. Por que, no longo prazo, o TDD na verdade economiza tempo da equipe de desenvolvimento?

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

  1. Faça o Commit: No GitHub Desktop, digite a mensagem (ex: Finaliza Capítulo 12 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_12_tdd.md
│   └── codigos/
│       └── cap12/
│           └── teste_tdd.cpp

💡 Checkpoint de Lógica

O TDD não é sobre testar o software. É sobre design. Escrever o teste antes força você a pensar em como a função será usada antes de tentar construí-la, gerando códigos muito mais simples e focados!

10. 🔥 Desafio de Fixação

Pesquise o que significa o termo Test Coverage (Cobertura de Testes).

🔑 Gabarito de Código/Fórmulas

Gabarito da Prática 1:

  1. Red (O teste falhou como esperado).
  2. Refactor (Melhorando a qualidade do código após ele funcionar).
  3. Green (Focando apenas em fazer o teste passar). Gabarito da Prática 2:
  4. Porque você encontra os erros no exato momento em que está digitando o código. Não há o risco de descobrir um bug semanas depois e ter que parar tudo para caçá-lo. Além disso, o código já nasce documentado pelos próprios testes!

← Capitulo Anterior | Proximo Capitulo →

Visão de gráfico

Backlinks