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)"| Comando | Cobre |
|---|---|
dataforge test . | descobre *_test.df e tests/ |
dataforge test --cobertura --minimo=80 | reprova o CI abaixo do piso |
dataforge test --fail-fast | para na primeira falha |
dataforge check . --strict | o que nem chega a rodar |
Continue em Testes de biblioteca e Crucible.