Skip to main content

Design decisions

description: "Index of Sendra design decisions: unasserted statuses under test, how exit codes are split, script sandboxing and the precedence chain."​

Design decisions

The rationale behind the design choices in Sendra's schema and CLI that could reasonably have gone another way - an ADR-style collection, one file per decision. For the shape of a feature (what a field is called, what it does), see docs/reference.md; these are the "why", not the "what".

  • Why test ignores an unasserted status — why a 404 nobody wrote an assertion against does not fail a sendra test run, and why a post_request script counts as a check the same way an assertion does.
  • Exit codes: why the numbers are split the way they are — why 4 is a separate number from 3, why an unsendable request under test exits 1 rather than 4, and how these codes rank against each other for a whole collection.
  • Sandboxing — the guarantees behind pre_request/ post_request: no filesystem, no network, nothing registered into the script interpreter beyond the request/response themselves.
  • Precedence, start to finish — every layer that can decide a value for a request — defaults, config, environment, captures, CLI overrides, pre_request — stated as one chain.