@riligar/test-kit

O sistema de testes da stack RiLiGar. Uma pasta, sete produtos, o produto não muda.

cd auth/worker
bunx riligar-test auth            # sobe o Auth em processo, roda a suíte
bunx riligar-test auth signup     # só a jornada de cadastro
bunx riligar-test smoke auth      # produção, só leitura
bunx riligar-test list            # suítes disponíveis

O princípio

O código de produção não sabe que está sendo testado. Nada de modo de teste, tabela de outbox, rota /_test/* ou flag de ambiente no produto. O kit se coloca em volta do serviço:

| O que o kit faz | Como, sem tocar no produto | | --- | --- | | Sobe um worker Cloudflare | Gera o mesmo bundle do deploy (wrangler deploy --dry-run) e o roda no Miniflare, neste processo, numa porta efêmera. | | Sobe um servidor Bun | Roda o entrypoint de produção como processo filho. | | Vê tudo o que o serviço tenta mandar para fora | Worker: outboundService do Miniflare. Bun: um preload injetado por BUN_OPTIONS, que redireciona fetch para o coletor do kit. E-mail vira { to, subject, links }. | | Semeia o banco | D1: handle em processo. SQLite: arquivo que o kit cria e passa por DB_PATH. | | Prova produção depois do deploy | Smoke só de leitura; rollback se falhar. |

O que o produto carrega: o devDependency, e — se for worker — um wrangler.test.jsonc sem binding remoto, para rodar sem login na Cloudflare.

Onde os testes moram

test-kit/
  suites/
    auth/        suite.config.js · setup.js · fixtures/ · journeys/
    monitors/    suite.config.js · journeys/
  src/           runner · http · runtime/ · capture/ · storage/ · checks/ · cli
  templates/     suite.config.js · journey.mjs · deploy.yml
  docs/          arquitetura, adoção, o porquê
  tests/         o kit testa a si mesmo

Cada produto é uma pasta em suites/. A suíte descreve como subir, o que semear e o que percorrer. Uma jornada é um módulo que recebe o contexto:

export const name = 'cadastro numa aplicação que nunca autenticou'

export default async function ({ t, api, capture, db }) {
    const r = await api.post('/auth/sign-up/email', { body: { email, password, name } })
    t.check('o cadastro é aceito', r.status === 200, r.status)

    const email = await capture.esperar({ kind: 'email', to: email })
    t.check('o link vai para o painel do produto', email?.links[0]?.startsWith(PAINEL), email?.links[0])
}

Suítes antigas que já existem no produto e falam HTTP por BASE continuam rodando, listadas em legacy, como processo filho contra o mesmo serviço.

Adotar num produto

1. Se for worker, um wrangler.test.jsonc sem send_email/routes/crons.
2. bun add -d @riligar/test-kit e "test": "riligar-test <produto>".
3. Uma pasta suites/<produto>/ no kit, a partir de templates/.
4. O workflow de templates/deploy.yml: testar → publicar → smoke → rollback.

Detalhes em docs/adocao.md. Como funciona por dentro em docs/arquitetura.md. Por que é assim em docs/porque.md.

Estado

Validado contra a stack real em 2026-09-07: a suíte inteira do Auth (jornada + 13 legados) roda em processo com o código do produto idêntico ao de produção; o Monitors sobe pelo cluster dele com a saída interceptada; o smoke passa nos sete produtos. Ainda não publicado no npm — enquanto isso os produtos usam file:../../test-kit, que funciona na máquina e não no CI.