Depuração e
mini-kata TDD

Ao final, você será capaz de.

Escrever é rápido. Achar é que demora

A média de um programador experiente é gastar mais tempo procurando a causa de um erro do que digitando a correção. A correção costuma ter uma linha; a investigação, três horas.

Três tipos de erro, três dificuldades

Ler o traceback inteiro

Traceback (most recent call last):
  File "app.py", line 22, in <module>
    print(media_turma(notas))
  File "app.py", line 15, in media_turma
    return soma / len(lista)
ZeroDivisionError: division by zero

O print estratégico

Colocar print nos pontos-chave é a técnica mais antiga e ainda a mais usada do mundo. Funciona — desde que os prints sejam rotulados.

print(x)
print(y)
print(total)

3
0
0

print("[loop] i =", i, "| total =", total)

[loop] i = 0 | total = 8
[loop] i = 1 | total = 6
[loop] i = 2 | total = 7

O depurador da IDE

O depurador (debugger) permite congelar o programa em qualquer ponto e olhar a memória por dentro, sem alterar uma linha do código.

Ver a memória mudando

Com o programa congelado, os painéis Locals (todas as variáveis do escopo atual) e Watch (as expressões que você escolheu vigiar) mostram os valores naquele exato instante.

O bug que não dá erro

notas = [8, 6, 7, 9]
total = 0

for nota in notas:
    total = nota          # ← sobrescreve!

print("Média:", total / len(notas))

Média: 2.25   (o certo seria 7.5)

Para que serve o Watch/Locals?

Durante a depuração de uma estrutura de repetição, qual é a finalidade principal da ferramenta de inspeção de variáveis?

Depurar é método científico

Explique para o patinho

Qual erro o computador não avisa?

E se o teste viesse antes?

Depurar é caro. A pergunta natural é: dá para escrever código de um jeito que gere menos bugs para caçar? Quando o teste vem depois, ele quase sempre é escrito para passar — a gente olha o código pronto e confirma o que ele já faz, inclusive os bugs. Quando vem antes, ele descreve o que o código deveria fazer.

O ciclo red · green · refactor

Red — o teste que falha

def testar_soma():
    # Arrange
    esperado = 7
    # Act
    obtido = calcular(3, 4, "+")
    # Assert
    assert obtido == esperado, \
        "3 + 4 deveria dar 7"

testar_soma()

Traceback (most recent call last):
  File "kata.py", line 10, in <module>
NameError: name 'calcular' is not defined

Green — o mínimo que passa

def calcular(n1, n2, op):
    if op == "+":
        return n1 + n2

testar_soma()

(sem saída — o assert passou em silêncio)

Novo comportamento, novo ciclo

def testar_divisao_por_zero():
    obtido = calcular(10, 0, "/")
    assert obtido is None, \
        "Divisão por zero deve devolver None"

testar_divisao_por_zero()

AssertionError: Divisão por zero deve devolver None

def calcular(n1, n2, op):
    if op == "+":
        return n1 + n2
    if op == "/":
        if n2 == 0:
            return None
        return n1 / n2

(silêncio: os dois testes passam)

Refactor — agora dá para melhorar

def calcular(n1, n2, op):
    """
    Executa uma operação aritmética simples.

    Args:
        n1 (float): primeiro operando.
        n2 (float): segundo operando.
        op (str): "+", "-", "*" ou "/".

    Returns:
        float: resultado da operação.
        None: se o operador for inválido ou
              se houver divisão por zero.
    """
    if op == "+":
        return n1 + n2
    if op == "-":
        return n1 - n2
    if op == "*":
        return n1 * n2
    if op == "/":
        return None if n2 == 0 else n1 / n2
    return None

OK: testar_soma
OK: testar_subtracao
OK: testar_multiplicacao
OK: testar_divisao
OK: testar_divisao_por_zero
OK: testar_operador_invalido

O teste passou de primeira

Antes de qualquer implementação. O que isso significa?

O que o TDD entrega — e o que ele cobra

O kata é de vocês

Depuração e TDD em oito linhas

• Leia a última linha do traceback antes de qualquer outra coisa
• Reproduza o erro de propósito antes de tentar corrigir
• Breakpoint antes do trecho suspeito; uma hipótese por vez
• Em laço, vigie o acumulador e a condição de parada
• Bug corrigido sem teste novo é bug que volta
• TDD: escreva o teste · veja o vermelho · só então implemente
• Implementação mínima: o suficiente para ficar verde, nada além
• Refatore somente com todos os testes passando