cuke_modeler 0.0.1

data/features/modeling/background_output.feature

@@ -0,0 +1,130 @@
+Feature: Outputting background elements
+
+  The output of an element model is a representation of the element as it would
+  appear in gherkin.
+
+
+  Scenario: Output of a background that does not have a name
+    Given a background element based on the following gherkin:
+    """
+    Background:
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    Background:
+    """
+
+  Scenario: Output of a background that does have a name
+    Given a background element based on the following gherkin:
+    """
+    Background: with a name
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    Background: with a name
+    """
+
+  Scenario: Output of a background that has a description, no first line buffer
+    Given a background element based on the following gherkin:
+    """
+    Background:
+    Some description.
+    Some more description.
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    Background:
+      
+      Some description.
+      Some more description.
+    """
+
+  Scenario: Output of a background that has a description, first line is blank
+    Given a background element based on the following gherkin:
+    """
+    Background:
+
+    Some description.
+    Some more description.
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    Background:
+      
+      Some description.
+      Some more description.
+    """
+
+  Scenario: Output of a background that has a description, first line is only whitespace
+    Given a background element based on the following gherkin:
+    """
+    Background:
+       
+    Some description.
+    Some more description.
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    Background:
+       
+      Some description.
+      Some more description.
+    """
+
+  Scenario: Output of a background that has steps
+    Given a background element based on the following gherkin:
+    """
+    Background:
+     * a step
+    |value|
+    * another step
+    \"\"\"
+      some string
+    \"\"\"
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    Background:
+      * a step
+        | value |
+      * another step
+        \"\"\"
+          some string
+        \"\"\"
+    """
+
+  Scenario: Output of a background that contains all possible parts
+    Given a background element based on the following gherkin:
+    """
+    Background: A background with everything it could have
+    Including a description
+    and then some.
+
+    * a step
+    |value|
+    * another step
+    \"\"\"
+      some string
+    \"\"\"
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    Background: A background with everything it could have
+      
+      Including a description
+      and then some.
+
+      * a step
+        | value |
+      * another step
+        \"\"\"
+          some string
+        \"\"\"
+    """

data/features/modeling/directory_modeling.feature

@@ -0,0 +1,120 @@
+Feature: Directories can be modeled.
+
+
+  Acceptance criteria
+
+    1. Directories containing feature files can be modeled:
+      - the directory's name
+      - the directory's full path
+      - all feature files contained
+      - all directories contained
+
+    2. Directories can be outputted in a convenient form
+
+
+  Background: Setup test directories
+    Given a directory "feature_directory"
+    And the following feature file "test_file_1.feature":
+    """
+    Feature: The test feature 1.
+
+      Scenario: The first scenario's name.
+        Given the first step
+        When the second step
+        Then the third step
+    """
+    And the following feature file "test_file_2.feature":
+    """
+    Feature: The test feature 2.
+
+      Scenario: The first scenario's name.
+        Given the first step
+        When the second step
+        Then the third step
+    """
+    And the following feature file "test_file_3.feature":
+    """
+    Feature: The test feature 3.
+
+      Scenario: The first scenario's name.
+        Given the first step
+        When the second step
+        Then the third step
+    """
+    And the following file "random.file":
+    """
+    Not a .feature file.
+    """
+    Given a directory "feature_directory/nested_directory"
+    And the following feature file "test_file_4.feature":
+    """
+    Feature: The test feature 1.
+
+      Scenario: The first scenario's name.
+        Given the first step
+        When the second step
+        Then the third step
+    """
+    And the following feature file "test_file_5.feature":
+    """
+    Feature: The test feature 2.
+
+      Scenario: The first scenario's name.
+        Given the first step
+        When the second step
+        Then the third step
+    """
+    And the following file "another_random.file":
+    """
+    Not a .feature file.
+    """
+    When the directory "feature_directory" is read
+    And the directory "feature_directory/nested_directory" is read
+
+  Scenario: The directory's name is modeled.
+    Then directory "1" is found to have the following properties:
+      | name | feature_directory |
+    And directory "2" is found to have the following properties:
+      | name | nested_directory |
+
+  Scenario: The directory's full path is modeled.
+    Then directory "1" is found to have the following properties:
+      | path | path_to/feature_directory |
+    And directory "2" is found to have the following properties:
+      | path | path_to/feature_directory/nested_directory |
+
+  Scenario: The directory's feature files are modeled.
+    Then directory "1" is found to have the following properties:
+      | feature_file_count | 3 |
+    And directory "1" feature files are as follows:
+      | test_file_1.feature |
+      | test_file_2.feature |
+      | test_file_3.feature |
+    Then directory "2" is found to have the following properties:
+      | feature_file_count | 2 |
+    And directory "2" feature files are as follows:
+      | test_file_4.feature |
+      | test_file_5.feature |
+
+  Scenario: The directory's directories are modeled.
+    Then directory "1" is found to have the following properties:
+      | directory_count | 1 |
+    And directory "1" directories are as follows:
+      | nested_directory |
+    Then directory "2" is found to have the following properties:
+      | directory_count | 0 |
+    And directory "2" has no directories
+
+  Scenario: Convenient output of a directory
+    Then the directory has convenient output
+
+  @redundant
+  Scenario Outline: Directory models pass all other specifications
+  Exact specifications detailing the API for directory models.
+    Given that there are "<additional specifications>" detailing models
+    When the corresponding specifications are run
+    Then all of those specifications are met
+  Examples:
+    | additional specifications     |
+    | directory_unit_spec.rb        |
+    | directory_integration_spec.rb |

data/features/modeling/directory_output.feature

@@ -0,0 +1,13 @@
+Feature: Outputting directory elements
+
+  The output of an element model is a representation of the element as it would
+  appear in gherkin.
+
+
+  Scenario: Output of a directory
+    Given a directory element based on "some_directory"
+    When it is outputted
+    Then the following text is provided:
+    """
+    path_to/some_directory
+    """

data/features/modeling/doc_string_modeling.feature

@@ -0,0 +1,63 @@
+Feature: Doc string elements can be modeled.
+
+
+  Acceptance criteria
+
+    1. All conceptual pieces of a doc string can be modeled:
+      - the doc string's content type
+      - the doc string's contents
+      - the doc string's raw element
+
+    2. Doc string can be outputted in a convenient form
+
+
+  Background: Test file setup.
+    Given the following feature file:
+    """
+    Feature:
+
+      Scenario:
+        * some wordy step:
+        \"\"\" content type
+      some text
+          
+            some more text
+        
+        \"\"\"
+        * some wordy step:
+        \"\"\"
+        \"\"\"
+    """
+    When the file is read
+
+
+  Scenario: The raw doc string element is modeled.
+    Then the doc string correctly stores its underlying implementation
+
+  Scenario: The doc string's content type is modeled.
+    Then the step "1" doc string content type is "content type"
+    And the step "2" doc string has no content type
+
+  Scenario: The doc string's contents are modeled.
+    Then the step "1" doc string has the following contents:
+      """
+      some text
+        
+          some more text
+      
+      """
+    And the step "2" doc string contents are empty
+
+  Scenario: Convenient output of an a doc string
+    Then the doc string has convenient output
+
+  @redundant
+  Scenario Outline: Doc string models pass all other specifications
+  Exact specifications detailing the API for doc string models.
+    Given that there are "<additional specifications>" detailing models
+    When the corresponding specifications are run
+    Then all of those specifications are met
+  Examples:
+    | additional specifications      |
+    | doc_string_unit_spec.rb        |
+    | doc_string_integration_spec.rb |

data/features/modeling/doc_string_output.feature

@@ -0,0 +1,71 @@
+Feature: Outputting doc string elements
+
+  The output of an element model is a representation of the element as it would
+  appear in gherkin.
+
+
+  Scenario: Output of an empty doc string
+    Given a doc string element based on the following gherkin:
+    """
+    \"\"\"
+    \"\"\"
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    \"\"\"
+    \"\"\"
+    """
+
+  Scenario: Output of a doc string without a content type
+    Given a doc string element based on the following gherkin:
+    """
+    \"\"\"
+    Some text
+      
+      some more text
+    
+    \"\"\"
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    \"\"\"
+    Some text
+      
+      some more text
+    
+    \"\"\"
+    """
+
+  Scenario: Output of a doc string with a content type
+    Given a doc string element based on the following gherkin:
+    """
+    \"\"\" the type
+    Some text
+      
+      some more text
+    
+    \"\"\"
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    \"\"\" the type
+    Some text
+      
+      some more text
+    
+    \"\"\"
+    """
+
+  Scenario: Output of a doc string with a triple quotes in its contents
+
+    Since triple quotes mark the beginning and end of a doc string, any triple
+    quotes inside of the doc string (which would have had to have been escaped
+    to get inside in the first place) will be escaped when outputted so as to
+    retain the quality of being able to use the output directly as gherkin.
+
+    Given a doc string element based on the string """" the type\n* a step\n  \"\"\"\n  that also has a doc string\n  \"\"\"\n""""
+    When it is outputted
+    Then the text provided is """" the type\n* a step\n  \"\"\"\n  that also has a doc string\n  \"\"\"\n""""

data/features/modeling/example_modeling.feature

@@ -0,0 +1,111 @@
+Feature: Example elements can be modeled.
+
+
+  Acceptance criteria
+
+    1. All conceptual pieces of an example block can be modeled:
+      - the example's name
+      - the example's description
+      - the example's parameters
+      - the example's rows
+      - the example's tags
+      - the example's applied tags
+      - the example's source line
+      - the example's raw element
+
+    2. Example blocks can be outputted in a convenient form
+
+
+  Background: Test file setup.
+    Given the following feature file:
+    """
+    @a_feature_level_tag
+    Feature:
+
+      @outline_tag
+      Scenario Outline:
+        * a step
+
+      Examples: text describing the significance of the examples
+            
+        Some example description.
+    
+      Some more.
+          Even more.
+        |param1| param2 | extra param |
+        |x     | y      |      ?      |
+        |1     | 2      |      3      |
+      @example_tag @another_one
+      Examples: some examples with different significance and a tag
+        | param1 |
+        | a      |
+    """
+    And parameter delimiters of "*" and "*"
+    When the file is read
+
+
+  Scenario: The raw example element is modeled.
+    Then the test example block correctly stores its underlying implementation
+
+  Scenario: The example's source line is modeled.
+    Then the test example block "1" is found to have the following properties:
+      | source_line | 8 |
+    And the test example block "2" is found to have the following properties:
+      | source_line | 18 |
+
+  Scenario: The examples' name is modeled.
+    Then the test example block "1" is found to have the following properties:
+      | name | text describing the significance of the examples |
+    And the test example block "2" is found to have the following properties:
+      | name | some examples with different significance and a tag |
+
+  Scenario: The examples' description is modeled.
+    Then the test example block "1" has the following description:
+      """
+          
+      Some example description.
+  
+      Some more.
+        Even more.
+      """
+    And the test example block "2" has no description
+
+  Scenario: The examples' tags are modeled.
+    Then the test example block "1" has no tags
+    And the test example block "2" is found to have the following tags:
+      | @example_tag |
+      | @another_one |
+
+  Scenario: The examples' applied tags are modeled.
+    Then the test example block "2" is found to have the following applied tags:
+      | @a_feature_level_tag |
+      | @outline_tag         |
+
+  Scenario: The examples' parameters are modeled.
+    Then the test example block "1" parameters are as follows:
+      | param1      |
+      | param2      |
+      | extra param |
+    And the test example block "2" parameters are as follows:
+      | param1 |
+
+  Scenario: The examples' rows are modeled.
+    Then the test example block "1" rows are as follows:
+      | x,y,? |
+      | 1,2,3 |
+    And the test example block "2" rows are as follows:
+      | a |
+
+  Scenario: Convenient output of an example block
+    Then the example block has convenient output
+
+  @redundant
+  Scenario Outline: Example models pass all other specifications
+  Exact specifications detailing the API for example block models.
+    Given that there are "<additional specifications>" detailing models
+    When the corresponding specifications are run
+    Then all of those specifications are met
+  Examples:
+    | additional specifications   |
+    | example_unit_spec.rb        |
+    | example_integration_spec.rb |