Module test_env 

#2134: a suite’s configuration, env { NAME = "value" … }.

A suite or case declares the variables and secrets its participants see. At system each participant’s Worker env holds them, as Wrangler would put them there; at unit/integration they are what the Secrets test double answers. One map applies to every participant, and a case’s env layers over its suite’s, name by name.

The checks here are tier-independent: a name given twice at one scope (bynk.suite.duplicate_env) and a value that is not a String literal (bynk.suite.env_not_literal). The system-only binding clash (bynk.suite.env_binding_clash) needs each Worker’s binding names, which the emitter computes, so it is check_env_binding_clash, called from there with them.

Functions

case_env

The variables and secrets case runs with: its suite’s env entries, overlaid by the case’s own, name by name. Only literal values are kept; a non-literal is already bynk.suite.env_not_literal.

check_env_binding_clash

bynk.suite.env_binding_clash: at system, an env entry lands on each participant’s Worker env, so a name one of them already binds (a Service Binding, KV namespace or Durable Object namespace), or a key the harness sets there itself (a call edge’s key, a foreign caller’s secret), is refused. bindings maps each such name to what holds it, as a phrase (“a binding of shop.ledger’s Worker”).

check_env_clauses

bynk.suite.duplicate_env and bynk.suite.env_not_literal for one suite declaration: its own env clauses as one scope, and each case’s as another.

has_env

Whether decl gives any env entry, at the suite or on a case.

remote_env_disagreement

#2138 (end-to-end testing track §3.7): a case run against a named target. A deployed target already runs with its own variables, so the runner can’t apply the case’s env; the case runs only if its env and the target’s declared vars agree on every name either mentions. Refused (bynk.test.remote_unsupported_env), first match reported: