Pular para o conteúdo

Testar código modular

Testar um módulo pelo caminho que um usuário usaria — e as duas armadilhas que fazem a suíte mentir.

Um teste que importa o módulo por um caminho que ninguém mais usa não prova que o módulo é utilizável.

dataforge
// packages/validador/tests/cpf_test.df
//
// CERTO: pelo NOME do pacote, como um usuario faria.
//   adopt validador as V
//
// ERRADO: por caminho relativo ate a fonte.
//   adopt ../src/main as V
//
// A segunda forma passa e nao prova nada sobre a instalacao. Foi
// ela que escondeu que um pacote nao sabia se importar pelo proprio
// nome: as suites dos VINTE pacotes deste repositorio falhavam, e o
// CI nao apanhava — ele nao rodava 'dataforge test' dentro de
// 'packages/'.

out "teste pelo caminho que o usuario usa"

As duas armadilhas#

O teste de um módulo#

dataforge
adopt Arcane.Crucible

crucible "normalizacao":
    trial "tira espaco e caixa":
        expect(normalizar("  Café  ")) to_be("café")

    trial "texto vazio nao quebra":
        expect(normalizar("")) to_be("")

    trial "ainda nao decidido" pending:
        expect(normalizar(void)) to_be("")

action normalizar(t):
    yield (t ?? "").strip().lower()

r := Crucible.run()
out $"{r['passou']} passaram, {r['pendente']} pendente(s)"
ComandoCobre
dataforge test .descobre *_test.df e tests/
dataforge test --cobertura --minimo=80reprova o CI abaixo do piso
dataforge test --fail-fastpara na primeira falha
dataforge check . --stricto que nem chega a rodar

Continue em Testes de biblioteca e Crucible.