Alois Mahdal 5ec3921b62 Removed GLOB hated by YAML 11 years ago
bin Moved to Dancer2 11 years ago
environments Changed strepo path to local (within repo) 11 years ago
examples Added description 11 years ago
lib Removed GLOB hated by YAML 11 years ago
notes Refactored field names 11 years ago
public Moved to Dancer 11 years ago
t Added tests for Condition error handling 11 years ago
views Restored original functionality within Dancer 11 years ago
.gitignore Added ignorance 11 years ago
AIM.md Added AIM document 11 years ago
MANIFEST Moved to Dancer 11 years ago
MANIFEST.SKIP Moved to Dancer 11 years ago
Makefile.PL Moved to Dancer 11 years ago
README.md Markup cleanup 11 years ago
TODO.md Added TODO for better error handling 11 years ago
config.yml Moved to Dancer 11 years ago
curltest-local.sh Added simple console curl tests 11 years ago
curltest.sh Added simple console curl tests 11 years ago

README.md

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.