بنقرة واحدة
run-tests
// Run and interpret Dada test results. Use when running tests, debugging test failures, or understanding test output.
// Run and interpret Dada test results. Use when running tests, debugging test failures, or understanding test output.
Conventions for authoring Rust code in the Dada compiler. Use when writing or modifying Rust code, adding functions, or making implementation changes.
RFC and specification workflow for Dada language features. Use when working with RFCs, writing spec paragraphs, or tracking implementation progress.
Track context across sessions for long-running features. Use when starting multi-session work, checkpointing progress, or resuming work on a feature tracked in a GitHub issue.
Write spec-aligned Dada tests. Use when creating new test files, organizing tests to match the specification, or adding test coverage for language features.
| name | run-tests |
| description | Run and interpret Dada test results. Use when running tests, debugging test failures, or understanding test output. |
# Run all tests
cargo dada test --porcelain
# Run tests in a directory
cargo dada test --porcelain tests/syntax/string_literals/
# Run a single test file
cargo dada test --porcelain tests/syntax/string_literals/type.dada
Always use --porcelain for machine-readable JSON output with structured failure information.
The --porcelain flag produces JSON with this structure:
{
"summary": { "total": 45, "passed": 45, "failed": 0, "duration_ms": 70 },
"tests": [
{
"path": "tests/syntax/string_literals/type.dada",
"status": "pass",
"annotations": ["#:skip_codegen", "#:spec syntax.string-literals.type"]
}
]
}
For failures, each test includes:
suggestion — Actionable guidance on how to resolve the failure. Read this first.details — Usually points to a .test-report.md file alongside the testWhen a test fails, a .test-report.md file is generated next to the test file. It contains:
#! annotations that didn't match any compiler output#? probes that got unexpected results#:spec syntax.string-literals.escape-sequences.backslash
Links the test to a spec paragraph. Validated against actual spec files.
#:skip_codegen # Skip WebAssembly generation (use for parser/type-check only tests)
#:fn_asts # Compare function AST output against .ref file
#!)Without carets — error can start anywhere on the previous interesting line:
print(unknown_var)
#! could not find anything named `unknown_var`
With carets — error span must match exactly (caret position = column on previous line):
fn test() { bad_name() }
#! ^^^^^^^^ could not find anything named `bad_name`
With regex — use / prefix (opening / only, NO closing /):
is_shared(x.mut)
#! /where clause.*not satisfied
Important: The regex convention uses
/patternwith NO closing/. Including a closing/causes the/to be part of the regex pattern, which will fail to match.
#?)let x = 22 + 44
#? ^^ ExprType: u32 # Type of expression at that span
#? ^ VariableType: u32 # Type of the variable
Caret position must align with the target on the previous line. VariableType shows the declared type (e.g., String not my String — the permission is on the expression, not the variable).
Probes also support regex with /:
#? ^ VariableType: /my.*String
#:skip_codegen#! annotations; the test passes when all expected errors match and no unexpected errors appear#? annotations; the test passes when all probes return expected values