Captures a data record used to initialise feature level data bindings
Base environment context providing access to all resources and services to engines.
Base trait for gwen evaluation engines.
Base trait for gwen evaluation engines. An evaluation engine performs the actual processing work required to evaluate individual Step expressions. This work can be done using various available frameworks and technologies. This trait serves as a base for concrete engine implementations coupled to specific such frameworks or technologies.
Evaluation engines are never invoked directly, but are rather invoked by the GwenInterpreter. This interpreter can mix in any evaluation engine that has this trait.
The context in which all engine instructions execute.
The context in which all engine instructions execute. The purpose of this context is to provide a place where common logic can be inserted before, after, or around an instruction.
Captures the results of an evaluated feature.
Returns an iteration of feature units for each entry in a given data file.
Captures the feature summary results of an evaluated feature.
Captures the feature summary results of an evaluated feature.
number of scenarios by status
number of steps by status
Captures a feature file and its associated meta as a unit.
Captures a feature file and its associated meta as a unit.
the feature file
the associated meta files (if any)
optional data record
Gwen interpreter application.
Interprets incoming feature specs by parsing and evaluating them.
Interprets incoming feature specs by parsing and evaluating them. All parsing is performed in the inherited gwen.dsl.GherkinParser. All evaluation is dispatched to a mixed in gwen.eval.EvalEngine.
Launches the gwen interpreter.
Captures gwen command line options.
Captures gwen command line options.
true to run in batch mode, false for interactive REPL (default is false)
true to run each given file/dir entry in parallel, false for serial (default is false)
optional directory to generate evaluation report into
list of properties files to load into system properties
list of tags to include and exclude (tag, True=include|False=exclude)
true to not evaluate steps on engine (and validate for correctness only)
optional CSV file for data driven testing (must include column headers in 1st line)
optional list of meta file overrides
optional list of feature file and/or directory paths
Read-Eval-Print-Loop console.
Merges two contexts into one.
Hybrid engine trait.
Manages and maintains an in memory stack of ScopedData objects for storing locally scoped StepDef parameters.
Binds data attributes to an arbitrary scope that has a name.
Binds data attributes to an arbitrary scope that has a name. Attributes are stored as name value pairs in a JSON sequence as follows:
{ "scope" : "name" "atts" : { "name1" : "value1", "name2" : "value2", ... "nameN" : "valueN" } }
When a new data attribute is added to the scope, it is appended to the end
of the atts
sequence. This is done internally. The order in which
attributes are stored reflects the same order in which they were added.
Once an attribute is added, it is never removed. If a same named attribute
is added more than once, then it will appear in the scope multiple times
(once for each time it is added).
When an attribute is looked up, its most recent (latest) entry is returned. For example, if the scope contains two attribute entries with the same name, then the value of the second entry is returned.
Data attributes are internally stored in immutable JSON data structures.
Manages and maintains an in memory stack of ScopedData objects for a particular scope and provides convenient access to all attributes.
Manages and maintains an in memory stack of ScopedData objects for a particular scope and provides convenient access to all attributes. Individual steps utilise this to access any data in the stack at any time. Collaborating steps can pass data to each other through this stack.
The scope at the top of the stack is always the currently active one. When a new scope is created, it is always added to the top of the stack. Therefore, newly created scope automatically becomes the currently active scope, and the previously active scope (and any others beneath it) move down one level in the stack.
Attributes are always bound to the currently active scope (the one at the top of the stack). They cannot be bound to any of the other non active scopes lower in the stack. Once an attribute is bound to a scope it is never removed from that scope, and therefore cannot be replaced. It can be overshadowed though by another attribute of the same name in a higher scope. In such cases where a scope contains multiple attributes of the same name, the most recently added scope always shadows the former when a lookup is performed.
Attributes can be looked up in one of two ways:
get
methodgetIn
methodAlthough their visibilities are different, both lookups return the first attribute found and scan from the top most visible scope down to the lowest. This ensures that the most recently bound value for an attribute is always returned if found.
Signals a step that failed to execute.
Feature result factory.
Reads and streams individual features and feature suites from the file system.
Reads and streams individual features and feature suites from the file system. An individual feature is a single feature file and optional meta file pair, whereas a feature suite is a directory containing one or many feature files, an optional meta file, and zero or many sub directories repeating the same structure. Both individual features and feature suites are streamed as [FeatureUnit] units. The former yields only one element and the latter yields many.
Feature summary factory.
ScopedData factory.
Checks that a feature satisfies all user provided include/exclude tags.
Checks that a feature satisfies all user provided include/exclude tags. Features that do not satisfy any of the provided tags are filtered out and returned as None types. Features having scenarios that satisfy all tags are pruned of all scenarios that do not and are wrapped and returned as Some types.
Base environment context providing access to all resources and services to engines. Specific evaluation engines can define and use their own specific context by extending this one.
Access to page scope data is provided through a dataScope method.