DEV Community

CrabPascal
CrabPascal

Posted on

Audit Deep Dive: Tests and Harness | Auditoria: testes e harness

#pascal #testing #opensource #devops

Bilingual post · Post bilíngue

Jump to: English · Português

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
Enter fullscreen mode Exit fullscreen mode

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:

  1. Parity tests where run and build-exe should match — skip with explicit reason when GCC is absent, never fake success.
  2. Minimal fixtures — one .pas file per bug, checked into tests/fixtures/.
  3. Harness isolation — Horse demos get offline smoke; full HTTP integration runs manually or in a dedicated pipeline.
  4. Living docs — update tests/README.md when 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
Enter fullscreen mode Exit fullscreen mode

Adding a test? Link the PR to a TD-ID (e.g. TD-TEST-001) and the sprint that owns it.

Mintlify reading path

  1. technical-debt/audit-overview — consolidated risk matrix
  2. technical-debt/audit/04-marina-tests-harness — Marina's full report
  3. roadmap/sprints/sprint-10-review — string parity gates
  4. 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
Enter fullscreen mode Exit fullscreen mode

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:

  1. Testes de paridade onde run e build-exe devem coincidir — skip com razão explícita sem GCC, nunca sucesso falso.
  2. Fixtures mínimos — um .pas por bug, versionado em tests/fixtures/.
  3. Isolamento de harness — demos Horse ganham smoke offline; integração HTTP completa roda manual ou em pipeline dedicado.
  4. Docs vivos — atualizar tests/README.md quando 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
Enter fullscreen mode Exit fullscreen mode

Adicionando teste? Ligue o PR a um TD-ID (ex.: TD-TEST-001) e ao sprint dono.

Trilha de leitura Mintlify

  1. technical-debt/audit-overview — matriz de risco consolidada
  2. technical-debt/audit/04-marina-tests-harness — relatório completo da Marina
  3. roadmap/sprints/sprint-10-review — gates de paridade de strings
  4. 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

Top comments (0)