# Fakes and the development call log

This is the detail behind [Tests and fakes](tests-and-fakes.md) and
[Provider calls in development](provider-calls-in-development.md): what a
fake answers, how a script is used, and what the call log keeps.

- **One fake per test, in every provider connection's place.** The test
  host gives a package's fake for
  each connection to a provider package, so a subscriber's call between
  the test's steps answers from the same script. An unscripted call
  answers with the operation's generated default.
- **The generated default** is the value of the operation's output type a
  provider would send, keeping its rules where a simple value can: text
  of its least length (`example` where that fits), a number at its least,
  the first plain variant, empty lists and maps, `null` for what is
  optional, the invocation's clock for an instant and its date, a fresh
  UUID. It is written as the provider sends it, its `wire_name:`
  spellings and `output_at:` envelope included, and read back through the
  operation's decoding, so a type whose rules no such value keeps (a
  pattern, say) faults where it is read, naming the field and the rule,
  and the test scripts it instead.
- **A scripted answer** is a value of the operation's output type, written
  and read back the same way; one of its failures, by its code; or a
  condition: `unavailable`, `lost` (the request went and no answer came:
  `outcome_unknown` for an unkeyed change, `unavailable` otherwise),
  `in_use` (the provider's key still in use) or `misconfigured`. A bare name is only a code or a condition, never
  a constant; an operation is scripted once, with at least one answer
  (`semantic.fake_invalid`). `fakes:` sits among the test's settings, and
  its answers are given to the fake before the test's first statement.
- **A script's use.** Each call of a scripted operation takes its next
  answer; a call past the last gets the generated default and fails the
  test as `test.fake_exhausted`, which reports in place of whatever the
  test went on to fail with, being the first thing that went wrong. Answers
  left fail a test that otherwise passed as `test.fake_unused`. Both name
  the operation, at its first scripted answer.
- **`jadpo dev`** gives every provider connection of the program it runs
  one driver: the sandbox, through the package driver, for what is
  let through; otherwise the fake, answering what `jadpo calls script`
  scripted, then the generated default. A provider connection's
  credential, environment or address setting that no variable or default
  gives gets a stand-in, so the app starts; such a connection stays faked
  whatever `sandbox:` says, and `jadpo dev` names the variables to set.
  Its environment set to `live` refuses to start, or to reload a save,
  with `cli.dev_start_failed` naming the variable and `--fake`. The
  session's `--sandbox` takes `connection.resource.operation` or
  `connection.resource`, and `--fake` a connection, each checked
  (`cli.dev_arguments`).
- **`development: { sandbox: }`** takes only `sandbox:`, a list of
  `resource.operation` and `resource` names, each once, each one of the
  package's public operations or resources (`connection.key_invalid`,
  `connection.value_invalid`).
- **Scripting by hand.** `jadpo calls script <operation> <answer>` takes
  an operation as the code calls it and one of its failures' codes or a
  condition, checked against the project's plan; a value can't be given on
  the command line. Each answer waits as a file of its own under
  `build/dev/script/`, oldest first, and the call that takes it removes
  it, so each answers one call, whichever worker makes it.
- **The call log** is `build/dev/calls.jsonl`, one call a line: its id
  (`call_31`, counted on from the last the log holds), when it went out,
  its connection and operation, its source (`generated`, `scripted`,
  `sandbox` and `recording`), its request's id, how long it
  took, the request as made (method, address and body, never its headers,
  which hold the credential) and the answer as sent or generated, and how
  it ended with a failure's code. It keeps the last 500 calls. A call
  `retry:` sends again is one
  entry, its last attempt's, where the invocation's own log
  keeps each attempt. Only provider calls are logged, a host's other capabilities'
  calls (files) are not, and a delivery's or a schedule's call has no
  request. Each request's line in `jadpo dev` lists its calls, and its
  `--json` event gives them.

> A script's `.requests` isn't built yet, nor are the timelines the call
> log would keep beside its calls.