English {#english}
Audit Deep Dive: Tests and Harness
Series — Part 2: Previous: Audit Deep Dive: RTL, Unicode, Properties (052-audit-rtl-unicode-properties). Report: technical-debt/audit/04-marina-tests-harness.
Marina's audit asks a blunt question: do our tests tell the truth? A compiler can pass cargo test while hiding run/build divergence, flaky Horse harnesses, and outdated README claims. For CrabPascal's sprint-driven roadmap, QA is not a checkbox — it is the contract that each release actually works.
Scope of the audit
Marina reviewed:
- Rust test suites under
tests/*.rs - Pascal fixtures in
tests/fixtures/*.pas - Example harness scripts, especially
tests/test_exemplos_completo.ps1 - Baseline health via
cargo test
The full evidence table is in Mintlify at technical-debt/audit/04-marina-tests-harness.
TD-TEST-001 — No run vs build parity tests (P1)
Most integration tests invoke run, not build or build-exe. Example: tests/properties_runtime.rs uses .arg("run") exclusively. The same pattern appears in string_conformance.rs, unicode_conformance.rs, and related suites.
Impact: Codegen regressions — incomplete properties, fake exception stubs (pre-v2.21.0), wrong string helpers — would not fail CI. Developers trust green builds that only exercise the interpreter path.
Fix direction: Sprint 10 (v2.18.0) introduced run_build_parity gates where GCC exists. The audit confirms we need this pattern everywhere parity matters.
# Today: most fixtures only do this
crab-pascal run tests/fixtures/properties_runtime.pas
# Needed: explicit build parity where toolchain available
crab-pascal build-exe tests/fixtures/properties_runtime.pas
TD-TEST-002 — Horse harness depends on live HTTP (P1)
tests/test_exemplos_completo.ps1 starts background jobs running CrabPascal servers, then calls Invoke-WebRequest against http://localhost:9001/api/....
Impact: CI fails offline. Timing flakes when the server is slow to bind. Reproducing failures requires Windows, PowerShell, and a free port.
Fix direction: Offline smoke tests, mock endpoints, or explicit skip with reason when HTTP is unavailable — targeted for Sprint 16.
TD-TEST-003 — Baseline cargo test not fully green (P2)
A unit test in src/semantic/mod.rs (test_undefined_variable) expects error messages containing "Undefined variable". The actual diagnostic text drifted, breaking the assert.
Impact: When baseline tests fail for message wording, teams ignore CI noise — and real regressions slip through.
Fix direction: Sprint 9 (v2.17.0) alignment — either update the expected string or standardize semantic error formatting.
TD-TEST-004 — tests/README.md version drift (P3)
The tests README still references CrabPascal v2.8.0 coverage claims. Post-v2.16.0 reality includes dozens of new fixtures, sprint gates, and parity tests not reflected there.
Impact: Contributors and stakeholders assume coverage that no longer matches the tree.
How tests run today (evidence snapshot)
| Suite | Command used | Gap |
|---|---|---|
properties_runtime.rs |
run |
No build comparison |
string_conformance.rs |
run |
C stubs untested in CI without gcc gate |
test_exemplos_completo.ps1 |
run + HTTP | Fragile in headless CI |
No existing suite was found calling crab-pascal build as a first-class CI step outside optional parity gates.
Recommended test philosophy
Marina's audit aligns with the squad principle in roadmap/squad: a test must fail if behavior regresses. That means:
-
Parity tests where
runandbuild-exeshould match — skip with explicit reason when GCC is absent, never fake success. -
Minimal fixtures — one
.pasfile per bug, checked intotests/fixtures/. - Harness isolation — Horse demos get offline smoke; full HTTP integration runs manually or in a dedicated pipeline.
-
Living docs — update
tests/README.mdwhen sprint acceptance criteria change.
Contributor quick start
cargo test # Rust unit + integration
crab-pascal check examples/crud/crud.dpr
crab-pascal run tests/fixtures/your_new_fixture.pas
Adding a test? Link the PR to a TD-ID (e.g. TD-TEST-001) and the sprint that owns it.
Mintlify reading path
-
technical-debt/audit-overview— consolidated risk matrix -
technical-debt/audit/04-marina-tests-harness— Marina's full report -
roadmap/sprints/sprint-10-review— string parity gates -
tests/README.md— local harness docs (needs refresh per TD-TEST-004)
Takeaway
Green tests that only exercise run create false confidence in native build paths. Marina's audit turns that into actionable backlog items with owners and recommended fixtures. Honest QA is what makes sprint releases trustworthy.
Next: Audit Deep Dive: IDE, CI, and Docs (054-audit-ide-ci-docs).
Português {#portugus}
Auditoria: testes e harness
Série — Parte 2: Anterior: Auditoria: RTL, Unicode, properties (052-audit-rtl-unicode-properties). Relatório: technical-debt/audit/04-marina-tests-harness.
A auditoria da Marina faz uma pergunta direta: nossos testes dizem a verdade? Um compilador pode passar cargo test enquanto esconde divergência run/build, harness Horse instável e claims desatualizados no README. Para o roadmap por sprints do CrabPascal, QA não é checkbox — é o contrato de que cada release realmente funciona.
Escopo da auditoria
A Marina revisou:
- Suítes Rust em
tests/*.rs - Fixtures Pascal em
tests/fixtures/*.pas - Scripts de harness de exemplos, especialmente
tests/test_exemplos_completo.ps1 - Saúde do baseline via
cargo test
A tabela completa de evidências está no Mintlify em technical-debt/audit/04-marina-tests-harness.
TD-TEST-001 — Sem testes de paridade run vs build (P1)
A maioria dos testes de integração invoca run, não build ou build-exe. Exemplo: tests/properties_runtime.rs usa .arg("run") exclusivamente. O mesmo padrão aparece em string_conformance.rs, unicode_conformance.rs e suítes relacionadas.
Impacto: Regressões de codegen — properties incompletas, stubs falsos de exception (pré-v2.21.0), helpers de string errados — não falhariam no CI. Desenvolvedores confiam em builds verdes que só exercitam o interpretador.
Direção de correção: Sprint 10 (v2.18.0) introduziu gates run_build_parity onde GCC existe. A auditoria confirma que precisamos desse padrão onde paridade importa.
# Hoje: a maioria dos fixtures só faz isso
crab-pascal run tests/fixtures/properties_runtime.pas
# Necessário: paridade build explícita quando toolchain disponível
crab-pascal build-exe tests/fixtures/properties_runtime.pas
TD-TEST-002 — Harness Horse depende de HTTP ao vivo (P1)
tests/test_exemplos_completo.ps1 inicia jobs em background rodando servidores CrabPascal, depois chama Invoke-WebRequest em http://localhost:9001/api/....
Impacto: CI falha offline. Flakes de timing quando o servidor demora a bindar. Reproduzir falhas exige Windows, PowerShell e porta livre.
Direção de correção: Smoke offline, endpoints mock ou skip explícito com razão quando HTTP indisponível — alvo Sprint 16.
TD-TEST-003 — Baseline cargo test não 100% verde (P2)
Teste unitário em src/semantic/mod.rs (test_undefined_variable) espera mensagens contendo "Undefined variable". O texto real do diagnóstico derivou, quebrando o assert.
Impacto: Quando testes de baseline falham por wording, times ignoram ruído no CI — e regressões reais passam.
Direção de correção: Alinhamento Sprint 9 (v2.17.0) — atualizar string esperada ou padronizar formatação de erros semânticos.
TD-TEST-004 — Drift de versão em tests/README.md (P3)
O README de testes ainda referencia cobertura CrabPascal v2.8.0. A realidade pós-v2.16.0 inclui dezenas de fixtures novos, gates de sprint e testes de paridade não refletidos lá.
Impacto: Contribuidores e stakeholders assumem cobertura que não corresponde mais à árvore.
Como os testes rodam hoje (snapshot)
| Suíte | Comando | Gap |
|---|---|---|
properties_runtime.rs |
run |
Sem comparação build |
string_conformance.rs |
run |
Stubs C não testados no CI sem gate gcc |
test_exemplos_completo.ps1 |
run + HTTP | Frágil em CI headless |
Nenhuma suíte existente foi encontrada chamando crab-pascal build como passo de CI de primeira classe fora de gates opcionais de paridade.
Filosofia de testes recomendada
A auditoria da Marina alinha com o princípio da squad em roadmap/squad: teste deve falhar se comportamento regredir. Isso significa:
-
Testes de paridade onde
runebuild-exedevem coincidir — skip com razão explícita sem GCC, nunca sucesso falso. -
Fixtures mínimos — um
.paspor bug, versionado emtests/fixtures/. - Isolamento de harness — demos Horse ganham smoke offline; integração HTTP completa roda manual ou em pipeline dedicado.
-
Docs vivos — atualizar
tests/README.mdquando critérios de aceitação de sprint mudarem.
Quick start para contribuidores
cargo test # unit + integração Rust
crab-pascal check examples/crud/crud.dpr
crab-pascal run tests/fixtures/seu_novo_fixture.pas
Adicionando teste? Ligue o PR a um TD-ID (ex.: TD-TEST-001) e ao sprint dono.
Trilha de leitura Mintlify
-
technical-debt/audit-overview— matriz de risco consolidada -
technical-debt/audit/04-marina-tests-harness— relatório completo da Marina -
roadmap/sprints/sprint-10-review— gates de paridade de strings -
tests/README.md— docs locais de harness (precisa refresh por TD-TEST-004)
Conclusão
Testes verdes que só exercitam run criam falsa confiança em caminhos de build nativo. A auditoria da Marina transforma isso em itens de backlog acionáveis com donos e fixtures recomendados. QA honesto é o que torna releases por sprint confiáveis.
Próximo: Auditoria: IDE, CI e documentação (054-audit-ide-ci-docs).
Published on dev.to/@crabpascal · Código em CrabPascal