Specification Testing

Tests validate the Product Graph itself - not generated code. Write assertions about state transitions, return values, authorization rules, and validation conditions directly in your .prd files. Tests run as part of the compiler pipeline, so spec-level issues are caught before any code is generated.

Transition Tests

Verify that workflows correctly transition entity state:

test issue_invoice_transition {
  target: issue_invoice
  given {
    invoice.status: draft
  }
  expect {
    transition: "invoice.status: draft -> issued"
    returns: ok
  }
}

Authorization Tests

Verify which actors are allowed or denied access to specific workflows:

test invoice_authorization {
  target: create_invoice
  expect {
    authorization {
      accountant: allowed
      viewer: denied
      customer: denied
    }
  }
}

Validation Tests

Test business rules with valid_when and invalid_when assertions:

test total_must_be_positive {
  target: total_positive
  expect {
    valid_when { total: 100 }
    invalid_when { total: 0 }
    invalid_when { total: -50 }
  }
}

Existence Tests

Verify that specific constructs exist in the Product Graph with the expected kind:

test task_entity_exists {
  target: task
  expect { kind: "entity" }
}

test task_has_title {
  target: task
  expect { has_property: "title" }
}

Test Structure

• target - Symbol reference to the construct being tested (entity, workflow, rule, etc.)
• given - Precondition state setup (e.g., entity field values before the workflow runs)
• expect - Assertions against a closed set of keys

Expect Keys (v0.1)

Running Tests

# Run spec tests only
prodara test --format json ./project

# Run tests as part of full build
prodara build ./project

# Tests produce structured JSON output
prodara test --format json ./project | jq '.results'

Unrecognized expect keys produce compilation errors, ensuring test assertions stay in sync with the language specification. Tests are also run automatically during prodara build.