Testes que passam e não provam nada

Peça "testes para essa função" e você recebe testes. Eles passam. A cobertura sobe. E o bug continua passando junto.

Há um motivo estrutural para isso: um teste que passa é a saída mais provável quando o pedido foi "escreva testes". Nada no pedido exigiu poder de detecção. E teste que passa parece sucesso — para o modelo e para quem lê rápido.

1. A asserção que não afirma nada

test('calcula o frete', () => {
  const r = calcularFrete(pedido);
  expect(r).toBeDefined();
  expect(typeof r).toBe('number');
});

test('frete é grátis acima de R$ 200 no subtotal', () => {
  expect(calcularFrete({ subtotal: 200.00, uf: 'PR' })).toBe(0);
  expect(calcularFrete({ subtotal: 199.99, uf: 'PR' })).toBe(24.90);
});

A diferença: A segunda versão testa a fronteira. 200,00 e 199,99 valem mais que dez casos no meio da faixa.

2. O mock que cobre justamente o que se quer testar

def test_aplica_desconto(mocker):
    mocker.patch('pedido.calcular_desconto', return_value=10.0)

    total = finalizar_pedido(pedido)

    assert total == 90.0   # 100 - 10

Mock existe para isolar o que é caro ou instável: rede, relógio, sistema de arquivos, serviço externo. Quando o mock cobre a regra de negócio, o teste vira decoração.

3. O teste espelho da implementação

public function test_calcula_total(): void
{
    $itens = [['preco' => 10.0, 'qtd' => 3]];

    $esperado = $itens[0]['preco'] * $itens[0]['qtd'];   // ← a mesma conta
    $this->assertSame($esperado, $this->carrinho->total($itens));
}

4. O teste que depende do relógio ou da ordem

$vencimento = date('Y-m-d', strtotime('+30 days'));
$this->assertSame($vencimento, $fatura->vencimento());

$this->travarRelogioEm('2026-01-31 10:00:00');

$fatura = $this->gerarFatura();

$this->assertSame('2026-03-02', $fatura->vencimento());

A diferença: Teste que depende de relógio, ordem de execução, rede ou estado deixado por outro teste não é teste — é sorteio. E o time aprende a reexecutar em vez de investigar.

5. Cobertura alta sem asserção relevante

É possível chegar a 90% de cobertura executando todas as linhas sem afirmar nada sobre elas. Cobertura mede o que foi executado, não o que foi verificado. Um relatório de cobertura alto com os quatro padrões acima é pior que nenhum relatório, porque cria confiança injustificada.

Escreva testes para a regra abaixo.

Regra: [Dado/Quando/Então com números]
Código: [cole]
Stack de teste: [framework e versão]

Regras obrigatórias:
- Cada teste afirma um valor concreto e esperado, escrito como constante.
  Proibido recalcular o esperado a partir da entrada.
- Proibido assertion genérica (toBeDefined, notNull, typeof).
- Cubra as fronteiras da regra, não só o caso do meio.
- Mock só para relógio, rede e sistema de arquivos. Nunca para a regra.
- Nenhum teste pode depender de data atual, ordem de execução ou
  estado deixado por outro teste.

Depois dos testes, responda: para cada teste, qual alteração no código
faria ele ficar vermelho? Se você não souber responder para algum,
esse teste é fraco — reescreva.

A última linha é a única medida honesta de qualidade de suíte — as outras quatro são atalhos rápidos.