cuke_modeler 0.0.1

data/features/modeling/scenario_output.feature

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

data/features/modeling/step_modeling.feature

@@ -0,0 +1,85 @@
+Feature: Step elements can be modeled.
+
+
+  Acceptance criteria
+
+    1. All conceptual pieces of a step can be modeled:
+      - the step's keyword
+      - the text of the step
+      - the step's arguments, if any
+      - the step's associated block, if any
+      - the step's source line
+      - the step's raw element
+
+    2. Steps can be outputted in a convenient form
+
+
+  Background: Test file setup.
+    Given the following feature file:
+    """
+    Feature:
+
+      Scenario:
+        Given some setup step
+        And some big setup step:
+        \"\"\" content_type
+      some text
+            some more text
+        \"\"\"
+        When this *parameterized* step takes a table:
+          | data      | a header |
+          | more data | a value  |
+        Then a step with a *parameter*
+    """
+    And parameter delimiters of "*" and "*"
+    When the file is read
+
+
+  Scenario: The raw step element is modeled.
+    Then the test step correctly stores its underlying implementation
+
+  Scenario: The step's source line is modeled.
+    Then the test step "1" source line is "4"
+    And  the test step "2" source line is "5"
+    And  the test step "3" source line is "10"
+    And  the test step "4" source line is "13"
+
+  Scenario: The step's keyword is modeled.
+    Then the test step "1" keyword is "Given"
+    And the test step "2" keyword is "And"
+    And the test step "3" keyword is "When"
+    And the test step "4" keyword is "Then"
+
+  Scenario: The text of the step is modeled.
+    Then test step "1" text is "some setup step"
+    And test step "2" text is "some big setup step:"
+    And test step "3" text is "this *parameterized* step takes a table:"
+    And test step "4" text is "a step with a *parameter*"
+
+  Scenario: The step's arguments are modeled.
+    Then test step "1" has no arguments
+    And test step "2" has no arguments
+    And test step "3" arguments are:
+      | parameterized |
+    And test step "4" arguments are:
+      | parameter |
+
+  Scenario: The steps's block is modeled.
+    Then step "1" has no block
+    Then step "2" has a "doc string"
+    And step "3" has a "table"
+    And step "4" has no block
+
+  Scenario: Convenient output of a step
+    Then the step has convenient output
+
+  @redundant
+  Scenario Outline: Step models pass all other specifications
+  Exact specifications detailing the API for step 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 |
+    | step_unit_spec.rb         |
+    | step_integration_spec.rb  |

data/features/modeling/step_output.feature

@@ -0,0 +1,52 @@
+Feature: Outputting step elements
+
+  The output of an element model is a representation of the element as it would
+  appear in gherkin.
+
+
+  Scenario: Output of a step without a block
+    Given a step element based on the following gherkin:
+    """
+    * a step
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    * a step
+    """
+
+  Scenario: Output of a step with a doc string
+    Given a step element based on the following gherkin:
+    """
+    * a step
+    \"\"\"
+    Some text
+
+      some more text
+    \"\"\"
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    * a step
+      \"\"\"
+      Some text
+      
+        some more text
+      \"\"\"
+    """
+
+  Scenario: Output of a step with a table
+    Given a step element based on the following gherkin:
+    """
+    * a step
+    |value1|
+    |value2|
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    * a step
+      | value1 |
+      | value2 |
+    """

data/features/modeling/table_modeling.feature

@@ -0,0 +1,52 @@
+Feature: Table elements can be modeled.
+
+
+  Acceptance criteria
+
+    1. All conceptual pieces of a table can be modeled:
+      - the table's contents
+      - the table's raw element
+
+    2. Tables can be outputted in a convenient form
+
+
+  Background: Test file setup.
+    Given the following feature file:
+    """
+    Feature:
+
+      Scenario:
+        * some data filled step:
+          | value 1 | value 2 |
+          | value 3 | value 4 |
+        * some data filled step:
+          | value 1 |
+          | value 2 |
+    """
+    When the file is read
+
+
+  Scenario: The table's contents are modeled.
+    Then the step "1" table has the following contents:
+      | value 1 | value 2 |
+      | value 3 | value 4 |
+    And the step "2" table has the following contents:
+      | value 1 |
+      | value 2 |
+
+  Scenario: The raw table element is modeled.
+    Then the table correctly stores its underlying implementation
+
+  Scenario: Convenient output of a table
+    Then the table has convenient output
+
+  @redundant
+  Scenario Outline: Table models pass all other specifications
+  Exact specifications detailing the API for table 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 |
+    | table_unit_spec.rb        |
+    | table_integration_spec.rb |

data/features/modeling/table_output.feature

@@ -0,0 +1,42 @@
+Feature: Outputting table elements
+
+  The output of an element model is a representation of the element as it would
+  appear in gherkin.
+
+
+  Scenario: Output of a table that has one row
+    Given a table element based on the following gherkin:
+    """
+    |value|
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    | value |
+    """
+
+  Scenario: Output of a table that has multiple rows
+    Given a table element based on the following gherkin:
+    """
+    |value1|
+    |value2|
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    | value1 |
+    | value2 |
+    """
+
+  Scenario: Whitespace buffers are based on the longest value in a column
+    Given a table element based on the following gherkin:
+    """
+    |value|x|
+    |y|another_value|
+    """
+    When it is outputted
+    Then the following text is provided:
+    """
+    | value | x             |
+    | y     | another_value |
+    """

data/features/modeling/table_row_modeling.feature

@@ -0,0 +1,67 @@
+Feature: Table Row elements can be modeled.
+
+
+  Acceptance criteria
+
+    1. All conceptual pieces of a table row can be modeled:
+      - the row's source line
+      - the row's cells
+      - the row's raw element
+
+    2. Rows can be outputted in a convenient form
+
+
+  Background: Test file setup.
+    Given the following feature file:
+    """
+    Feature:
+
+      Scenario:
+        * some data filled step:
+          | value 1 | value 2 |
+          | value 3 | value 4 |
+        * some data filled step:
+          | value 1 |
+          | value 2 |
+    """
+    When the file is read
+
+
+  Scenario: The raw table row element is modeled.
+    Then the step table row correctly stores its underlying implementation
+
+  Scenario: The table row's source line is modeled.
+    Then step "1" table row "1" is found to have the following properties:
+      | source_line | 5 |
+    And step "1" table row "2" is found to have the following properties:
+      | source_line | 6 |
+    And step "2" table row "1" is found to have the following properties:
+      | source_line | 8 |
+    And step "2" table row "2" is found to have the following properties:
+      | source_line | 9 |
+
+  Scenario: The table row's cells are modeled.
+    Then step "1" table row "1" cells are as follows:
+      | value 1 |
+      | value 2 |
+    And step "1" table row "2" cells are as follows:
+      | value 3 |
+      | value 4 |
+    And step "2" table row "1" cells are as follows:
+      | value 1 |
+    And step "2" table row "2" cells are as follows:
+      | value 2 |
+
+  Scenario: Convenient output of a table row
+    Then the table row has convenient output
+
+  @redundant
+  Scenario Outline: Table row models pass all other specifications
+  Exact specifications detailing the API for table table row 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     |
+    | table_row_unit_spec.rb        |
+    | table_row_integration_spec.rb |