Jargon

This page collects various terms that have specific meanings in the context of act-tester. These will eventually probably be documented in a more formal setting.

Naturally, these terms will change as we work out better things to call bits of the tester.

Terms used outside of the codebase

Stages, cycles, and the director

The tester has several distinct stages, each having a ’-er’ name:

• Planner
• Fuzzer
• Lifter
• Invoker
  • Compiler
  • Runner
• Analyser

Going through each of these stages once produces a cycle. (Parts of the tester call this a run or an iteration, but will be renamed eventually.) A cycle, then, involves a set of particular test subjects, being the fuzzed results of whatever subjects went into the planner.

The director is a program that runs multiple cycles, one per machine.

Machine nodes

The machine node is the separate binary that lives on the target machine. It compiles recipes and then runs their binaries.

Compilers and configurations

A compiler is somewhat self-explanatory. Currently, all compilers live on the same machine as the machine node, but if the tester ever learns how to cross-compile this may change.

A compiler configuration is a combination of a compiler and the specific settings and flags to use when invoking it. A compiler can produce many configurations. (Currently, this is backwards in the codebase, but will change eventually.)

Backends and recipes

A backend is an external program that accepts a subject and turns it into a compilable artefact. (This is always Litmus, at time of writing.)

A recipe is a series of steps to be passed to the machine node that say how to compile a backend output.

Plans, corpora, subjects, compilations, and runs

A plan is a mostly self-contained bundle of information about one testing session.

Each plan contains one corpus (pl. corpora), which has zero or more subjects (elsewhere called test-cases).

A compilation is a pair (subject, configuration). A run is the result of running a compilation.

Each subject eventually accumulates information, including:

• Recipes for each architecture under which the subject is being compiled;
• Information about each compilation and run;

Terms used inside the codebase

These get used quite often inside the codebase, but don't really have any particularly useful meaning outside of it.

Services and drivers

Backends and compilers are specific types of service (external program).

Generally, any interface parameter that tells part of the tester how to talk to a service is called a driver.

Instances

Generally, anything that is spawned by a stage (or similar) to handle a particular input (usually a plan) is an instance. (Parts of the tester call this a job, but will be renamed eventually.)

Observers

A lot of the codebase uses the observer pattern, and the usual pattern is for things to accept a slice of some sort of observer interface containing functions that the recipient should call into when it has done something worth (pseudo-)asynchronously observing.

Observers appear synchronous at call site, but could theoretically hide channel sends and/or asynchronous activities. Maybe, one day, they'll become explicit channels.

Quantities

Quantities are integer parameters such as number-of-workers and timeouts that can be set either in the main config or in command-line flags.

Options

Increasingly large amounts of the codebase also use the functional updates pattern. Where there is an options.go containing an Option type, this is that.

There are a few common options:

• Options bundles multiple options into one option;
• ObserveWith appends observers onto something's observer list;
• OverrideQuantities overrides the quantity set something is using with another quantity set; anything that is nonzero in the new set replaces its counterpart in the old set.

Jobs

Inside the tester, there are often pieces of information passed around containing a subject and some context on what to do with it (usually information about a service). These are jobs.