Projetando e testando regras

Objetivo da aula

Transformar uma regra textual em condições e casos de teste.

Regra desta aula: vamos assumir que você nunca viu este assunto antes. Nenhum termo importante será usado sem explicação e todo exemplo deve ser entendido linha por linha, não apenas copiado.

Começando do zero

Uma regra de negócio é uma decisão que representa uma regra do problema: desconto, aprovação, faixa, acesso, prioridade. A parte difícil não é escrever if; é garantir que a regra foi entendida, que as fronteiras estão corretas e que casos importantes foram testados.

Uma imagem mental para entender

Imagine criar regras para uma fila de parque. Se a placa diz “crianças até 12 anos”, você precisa decidir se 12 entra e 13 não. O erro costuma aparecer exatamente nesses limites. Escrever testes antes de confiar na regra evita surpresas.

Conceitos essenciais, sem pular etapas

Escreva a regra em português

Antes do código: “se a compra for pelo menos R$ 200, desconto de 10%; caso contrário, sem desconto”. Isso torna explícita a intenção.

Identifique entradas e saída

Quais dados a regra precisa? O que ela produz? Um percentual, uma categoria, uma autorização?

Marque as fronteiras

Valores exatamente iguais aos limites devem ser previstos. Se a regra diz “pelo menos 200”, o operador provável é >=.

Tabela de casos

Liste entradas representativas: abaixo, exatamente no limite e acima. Para múltiplas condições, combine casos que exercitem cada ramo.

Separe validação de classificação

Antes de classificar uma nota, verifique se ela está na faixa aceita. Um valor inválido não deveria ser silenciosamente classificado como se fosse legítimo.

Modelo mental

REGRA EM PALAVRAS → ENTRADAS/SAÍDA → FRONTEIRAS → CÓDIGO → CASOS DE TESTE

Exemplo 1 — primeiro veja o programa inteiro

compra = 200.00

if compra >= 200:
    taxa_desconto = 0.10
else:
    taxa_desconto = 0.0

valor_desconto = compra * taxa_desconto
total = compra - valor_desconto

print(f"Desconto: R$ {valor_desconto:.2f}")
print(f"Total: R$ {total:.2f}")

Agora vamos ler linha por linha

A frase “pelo menos 200” foi traduzida para >= 200.
O ramo decide apenas a taxa; o cálculo comum vem depois da estrutura.
Isso evita duplicar a fórmula do total em dois ramos.
O caso exatamente 200 é especialmente importante para o teste de fronteira.

Saída esperada

Desconto: R$ 20.00
Total: R$ 180.00

Exemplo 2 — o mesmo conceito em outra situação

casos = [199.99, 200.00, 200.01]
for compra in casos:
    desconto = compra >= 200
    print(compra, desconto)

Esse pequeno teste usa um laço que veremos em detalhe adiante, apenas para mostrar uma ideia poderosa: testar valores logo abaixo, no limite e logo acima.

Experimento guiado

Não pule esta parte. Programação só começa a fazer sentido quando você prevê um resultado, executa e compara a previsão com o que realmente aconteceu.

Escreva a regra em linguagem natural antes de codificar.
Liste três casos para um limite: abaixo, igual e acima.
Teste cada ramo da estrutura pelo menos uma vez.
Quando houver dado inválido, defina explicitamente o comportamento esperado em vez de deixar o valor “cair” em alguma categoria.

Mini desafio

Crie uma regra de frete: grátis para pedidos de R$ 150 ou mais; R$ 20 para pedidos abaixo desse valor. Teste 149.99, 150 e 150.01.

Solução comentada

pedido = 150.00
if pedido >= 150:
    frete = 0.0
else:
    frete = 20.0
print(f"Frete: R$ {frete:.2f}")

Depois de executar a solução, altere pelo menos um valor e explique por que o novo resultado mudou. Se você só copiou e não consegue explicar cada linha, refaça o desafio em uma versão menor.

Erros comuns e por que acontecem

Codificar antes de conseguir explicar a regra em uma frase.
Usar > quando o texto dizia “maior ou igual”.
Testar apenas um valor “normal” e esquecer fronteiras.
Duplicar cálculos idênticos dentro de vários ramos.

Cheque se você realmente entendeu

Qual valor é essencial ao testar uma regra `>= 200`?

Resposta: O próprio 200, além de valores imediatamente abaixo e acima.

Por que escrever a regra em português primeiro?

Resposta: Para separar entendimento do problema da sintaxe da linguagem.

Uma entrada inválida deve cair automaticamente na faixa mais baixa?

Resposta: Não necessariamente; o comportamento deve ser definido explicitamente pela regra.

Resumo em linguagem simples

Nesta aula, o ponto central foi Projetando e testando regras. Tente explicar o modelo REGRA EM PALAVRAS → ENTRADAS/SAÍDA → FRONTEIRAS → CÓDIGO → CASOS DE TESTE sem olhar a tela. Depois, escreva um exemplo próprio menor que os apresentados. Esse exercício de explicação é parte do aprendizado, não um extra.

Conexão com a próxima aula

Na próxima aula, Por que repetir, vamos aproveitar exatamente o que foi construído aqui. Você não precisa memorizar tudo; precisa conseguir reconhecer o conceito e reconstruí-lo com raciocínio e testes.

Projetando e testando regras