# Input

The input is the data the code under test runs on.

Methods are not distinguished by the input's surface. Arguments, file
contents, packets, the clock's readings, even the scheduler's interleaving
choices are all just bits the program reads (a deterministic-simulation
harness turns scheduler interleavings into seed-driven bits). Two
orthogonal things distinguish methods instead:

- **Source** — where the input comes from: pinned by the author
  (**fixed**), produced from a bit source under some steering signal
  (**generative**), or taken from the running system (**live**).
- **Shape** — whether those bits are used raw or decoded through a schema
  into a well-formed, structured value.

<figure class="axis-tree" markdown>

- **Fixed**
- Generative
    - **random**
    - **feedback**
    - **solver**
    - **exhaustive**
- **Live**

</figure>

## Source — where do the bits come from?

- **Fixed.** Pinned at authoring time; no RNG — the value *is* the input.
  Example tests, [snapshot / approval](https://quality.stereobooster.com/snapshot-testing.md),
  acceptance / BDD.
- **Generative.** Produced from a bit source. Random sampling is *blind*; the
  other three are *steered*, each using a signal to pick the next input:
    - **Random.** Blind sampling. Dumb fuzzing; property-based testing's
      default seed stream.
    - **Feedback** — a runtime signal used to steer. Usually code coverage
      ([AFL++](https://github.com/AFLplusplus/AFLplusplus), [libFuzzer](https://llvm.org/docs/LibFuzzer.html); targeted property-based
      testing via [Hypothesis](https://hypothesis.readthedocs.io/) `target()`), or a fitness
      function a metaheuristic optimizes, as in
      [search-based testing](https://quality.stereobooster.com/search-based-software-testing.md).
    - **Solver** — constraint-solving derives bits that reach a path.
      Symbolic / concolic execution ([KLEE](https://klee-se.org/), SAGE).
    - **Exhaustive / systematic** — enumeration deliberately covers the
      (bounded) space. Combinatorial (pairwise), boundary /
      equivalence partitioning, bounded model checking.
- **Live.** The bits come from the running system, not the harness — real
  production traffic, neither pinned nor synthesized. Parallel run multicasts
  it to two implementations; production monitoring observes it as it arrives.

## Shape — a decoder layered on top

A **schema** is a function $\text{bits} \to \text{well-formed value}$:
it decodes the bit source, random *or* steered, into a structured input.
A generator is this — $\mathsf{Gen}\ a \approx \mathsf{Seed} \to a$, a
bit source plus a decoder. Shape is orthogonal to the source:

|            | unshaped (raw bits)             | shaped (schema decoder)                                          |
| ---------- | ------------------------------- | ---------------------------------------------------------------- |
| **random** | dumb fuzzing (radamsa)          | property-based testing ([QuickCheck](https://hackage.haskell.org/package/QuickCheck), Hypothesis)                  |
| **steered** | coverage fuzzing on bytes (AFL) | structure-aware fuzzing (libFuzzer + `arbitrary`); targeted PBT  |

Structure-aware fuzzing takes the coverage-guided byte stream and runs it
through a PBT-style generator to get a valid structured input — same shape
layer, RNG swapped for a steered source.

Shape isn't strictly all-or-nothing: a generator *constructs* valid values, but
the same effect comes from reject / `assume` — filtering the raw stream rather
than building from it, at worse efficiency. Shrinking is a separate post-find
concern, not part of the input axis.

## Mapping to the established vocabulary

The standard survey of automated test-case generation (Anand et al. 2013)[^anand2013]
enumerates five methodologies, which map onto the source-and-shape tree:

- **Random testing** (and *adaptive random testing*) ≈ `generative random`.
- **Search-based testing** ≈ `generative feedback` —
  coverage-guided fuzzing is search over the input space.
- **Symbolic / concolic execution** ≈ `generative solver`.
- **Combinatorial testing** ≈ `generative exhaustive`.
- **Model-based testing** (Utting et al. 2012)[^utting2012] ≈ the **shape** layer: a schema or
  state-machine model that decodes bits into valid, structured inputs.

## Referenced by

- [Effect scope](https://quality.stereobooster.com/effect.md) · The axes
- [Guarantee](https://quality.stereobooster.com/guarantee.md) · The axes
- [The axes](https://quality.stereobooster.com/axes.md) · The axes
- [Methods](https://quality.stereobooster.com/methods.md) · Methods

## References

[^anand2013]: Anand, Saswat, Edmund K. Burke, Tsong Yueh Chen, et al. 2013. "[An Orchestrated Survey of Methodologies for Automated Software Test Case Generation](https://romisatriawahono.net/lecture/rm/survey/software%20engineering/Software%20Testing/Anand%20-%20Automated%20Software%20Test%20Case%20generation%20-%202013.pdf)." *Journal of Systems and Software* 86 (8): 1978–2001. <https://doi.org/10.1016/j.jss.2013.02.061>.
[^utting2012]: Utting, Mark, Alexander Pretschner, and Bruno Legeard. 2012. "[A Taxonomy of Model-Based Testing Approaches](https://eprints.qut.edu.au/57853/1/master_pdflatex.pdf)." *Software Testing, Verification and Reliability* 22 (5): 297–312. <https://doi.org/10.1002/stvr.456>.

## Acronyms

- BDD — behavior-driven development
- PBT — property-based testing
- RNG — random number generator