sugar-trail
===========

Set of syntax rules and a PL to allow for easy writing of test procedures.


##Synopsis##

    Header: value of any kind
    Other-header: name1=value1; name2=value2
    Another-one: something else

    After an empty line, body starts.  (Just like MIME.)  The body is
    basically just Markdown with some modifications discussed later.

    #case name#
    1. instruction
       > expected result (or check point, or oracle)
       > another expected result {fam>10} {os~win*}
    2. cond. instruction
       * yes: opt 1
       * no: opt 2
    0. Assertion (specifically zero, can be anywhere)
    3. another instruction


##Description##

Basic form is similar to MIME.  First headers, then, after one empty line, the
body, up to the EOF.  Just like in MIME, headers are only for meta-data--they
are not visible in the final output.

Inside header, various parameter ranges like OSes, architectures, product
editions or hardware types can be declared.  Later, presence of entities (e.g.
instructions) can be conditioned using these.

This is also meant to allow for generation of set of ready procedures with
variations of parameters.


##Rules##

*   if assertion -or- instruction fails
    *   IN is generated
    *   rest of test case is skipped

*   if expected result fails
    *   IN is generated
    *   TC goes on

##Terms##

*   *IN* - incident note
    *   note itself
    *   bug report against tested subject?
    *   bug report against test documentation?

*   *TC* - test case

*   *ST* - sugar trail (trail of test cases)


##Example##

See [examples/fridge_ops.md](examples/fridge_ops.md).