Class SpecTest

java.lang.Object
io.nosqlbench.nb.spectest.core.SpecTest
All Implemented Interfaces:
Runnable
public class SpecTest extends Object implements Runnable
This is the entry point into a specification test. By default, all files within the provided path are checked for the scanner patterns, and all validators are run. This means:
  1. All provided paths which are markdown files will be scanned.
  2. All provided paths which are directories will be recursively scanned for contained markdown files.
  3. Every included markdown file will be scanned for matching element sequences.
  4. Every matching element sequence will be validated.

The details of each of these steps should be documented in the specific classes which implement the behavior. At a high level: Key concepts are:

  • Specification Files - These are the markdown files and included sets of specification tuples. Specification tuples are sequences of content elements which are recognizable by a scanner as going together to form a multi-part specification and test.
  • Scanners - A scanner is a pattern matcher specification, in the form of a set of predicate objects. These are tested against sequences of elements that are found within specification files. Each time a scanner matches a sequence of elements, a specification template is extracted and submitted to a set of validators.
  • Specification Template - This is merely a set of content elements which represents a specific specification or example. When a specification template is found, it is extracted with some context metadata that makes it easy to identify and report (like the heading), as well as the content needed for a specification validator to confirm whether or not it passes a test for validity.
  • Validators - A validator knows how to assert the validity of a specification template. It is essentially a set of test assertions against a specification template. There are default validators which do different types of validation based on the content type.
Effectively, all specifications are described prosaically within the markdown, while the actual specifications which are meant to be validated are captured within fenced code sections. The type of fenced code section determines how the inner content is interpreted and validated.