Jadpo is experimental and not ready for production. These docs follow the compiler's main branch as of 30 Oct 2026. What's built · Install 0.1.0
jadpo
Reference: Testing

Testing

Configuration in tests

On this page

A test never reads your machine's environment. Each configuration field gets its value in a test from config.jadpo: its test: value, or else its default: (Defaults and test values). So a test gives the same answer everywhere. A test changes a field for itself, and the code it calls, with its config: setting:

example
type FromAddress = Email {}config {    mail_api_key: Text {        secret: true    }    mail_sender: FromAddress {        test: "reminders@example.test"    }}function address() -> FromAddress {    return config.mail_sender}test "reminders come from the test sender" {    assert address() == "reminders@example.test"}test "a test can change the sender" {    config: {        mail_sender: "planning@example.test"    }    assert address() == "planning@example.test"}

Secrets

Secrets never appear in test source. Each test run gets a generated throwaway value for each one. That is enough, because a secret can only reach places the compiler owns, such as signing and integration credentials, and integrations are faked in tests. A secret in a test's config: is configuration.secret_default.

What the compiler checks

A field that tested code reads with no test:, default: or config: value is a compile error, configuration.test_value_missing. The compiler follows the functions, actions and fixtures a test calls to find these reads. A name in a test's config: that is no field is configuration.field_unknown. A value in config: is checked as a default: is.

Markdown for agents: /docs/configuration-in-tests.md.Built from Jadpo main at a707efb.