Sha256: f6e28a56cca2762bd405b428fa4676599e074953814807f6c3cac4d0e5ba8cc6
Contents?: true
Size: 1.84 KB
Versions: 31
Compression:
Stored size: 1.84 KB
Contents
Feature: Model structure
When modeling an existing test suite, that suite is parsed and models are created for each element of the suite. These models form a nested structure of parent and child models which has the same shape as whatever portion of the suite that they represent (see the documentation for specific models for details).
However, all models can also be used in an 'abstract' manner. That is, they can be created without any input (such as a file path or snippet of Gherkin) that would normally be used for determining their structure and properties. In these cases, their parent/child relationships and properties can be set directly rather than being populated dynamically based on an actual test suite.
Scenario: Creating abstract models
Given the models provided by CukeModeler
Then all of them can be created without further context
"""
abstract_model = <model_class>.new
"""
Scenario: Nesting models
Given the models provided by CukeModeler
Then all of them can contain other models
"""
child_model = <model_class>.new
parent_model = <model_class>.new
parent_model.children << child_model
"""
And all of them can be contained inside of another model
"""
child_model = <model_class>.new
parent_model = <model_class>.new
child_model.parent_model = parent_model
"""
Scenario: Accessing the parsing data
Note: Directory models do not store any parsing data because parsing Gherkin source text does not come into play until the feature file level of modeling.
Given the models provided by CukeModeler
Then all of them provide access to the parsing data that was used to create them
"""
model = <model_class>.new(<source_text>)
model.parsing_data
"""
Version data entries
31 entries across 31 versions & 1 rubygems