QC tests are defined and parametrised out of source in YAML files. In the project definition file, the `qc.definitions` and `qc.parameters` keys point to, respectively, the definition and parametrisation files for the QCs to be applied to a given project.
Different QCs may be defined for different projects by saving them to separate definition files; conversely, the same QCs may be reused across projects.
The parameters for each QC test are saved to a separate file. This is to allow QCs to be reused across projects, possibly with different parameters.
## Running
For all projects that have QCs defined, the tests can be run by calling the [`lib/www/server/lib/qc.js`](/lib/www/server/lib/qc.js) script. This can be done from a cronjob, e.g.,:
```cron
# max-old-space-size increases the memory available to Node.js, to deal with complicated tests or large projects.
The QC definition YAML file should consist of a list of tests. These may be organised hierarchically if the user wishes to do so.
A QC definition consists of the following attributes:
Attribute | Description
--------------|-------------
`name` | A short name for the test or hierarchical group.
`description` | A more detailed description. Markdown is accepted.
`disabled` | If `true`, the test or branch will not be run.
`iterate` | What to iterate over. It can take one of three values: `shots`, `sequences` or `lines`. If not present it defaults to `shots`, which means the script will be called once per every shot in the prospect.
`labels` | Array of labels to apply to the test or to the branch.
`children` | Any element having a `children` attribute becomes a branch. The contents of this attribute are a list of tests or branches, same as the top-level list.
`check` | A script consisting of JavaScript code which defines the test that is to be run. Tests that pass should return **`true`** whereas failing tests should return a string with a message describing the failure. Note that it is valid to have both `check` and `children` in the same item.
### Test definitions
Tests can be defined as arbitrary JavaScript, which will be run in a sandbox. The sandboxed code does not have access to the filesystem or the `console` object.
The result of the test is the last expression evaluated by the script. This should be the primitive **`true`** if the test is successful, or a string describing the failure if it is not.
The script has access to the following variables:
#### `parameters`
An object containing all the parameter definitions for the project, for instance:
```javascript
{
gunDepth: 6,
gunDepthTolerance: 0.5,
gunTiming: 0.9999,
gunTimingSubarrayAverage: 0.5,
gunPressureNominal: 2000,
gunPressureToleranceRatio: 0.025,
crosslineError: 12,
crosslineErrorAverage: 9,
inlineErrorRunningAverageValue: 2,
inlineErrorRunningAverageShots: 40
}
```
#### `currentItem`
The item being iterated over. This can be of type `Shot`, `Sequence`, or `Preplot` depending on the value of this test's `iterate` attribute.
Each of the above objects has a function named `_`. This is a helper to quickly access own nested attributes without having to check if the attribute or one of its parents exist. For instance, on a `Shot` item, `currentItem._('raw_meta.smsrc')` will return the SmartSource gun data if it exists, or undefined if either `smsrc` or `raw_meta` are not defined.
