cucumber_analytics 1.4.2 → 1.5.0

data/History.rdoc

@@ -1,3 +1,10 @@
+=== Version 1.5.0 / 2014-02-04
+
+* Version ranges have been added for gem dependencies.
+* #to_s has been overridden for elements so that it returns text suitable for
+  use as gherkin source code.
+
+
 === Version 1.4.2 / 2014-01-26
 
 * Bug fix: Example#add_row no longer assumes that the key/value pairs in a

data/README.rdoc

@@ -1,5 +1,9 @@
 = CucumberAnalytics
 
+{<img src="https://badge.fury.io/rb/cucumber_analytics.png" alt="Gem Version" />}[http://badge.fury.io/rb/cucumber_analytics]
+{<img src="https://gemnasium.com/enkessler/cucumber_analytics.png" alt="Dependency Status" />}[https://gemnasium.com/enkessler/cucumber_analytics]
+{<img src="https://codeclimate.com/github/enkessler/cucumber_analytics.png" />}[https://codeclimate.com/github/enkessler/cucumber_analytics]
+
 The intention of this gem is to provide a useful mechanism by which to answer
 all of the burning questions that one might have about their Cucumber test base.
 

data/Rakefile

@@ -11,7 +11,7 @@ end
 
 desc 'Run all acceptance tests for the gem'
 Cucumber::Rake::Task.new(:tests) do |t|
-  t.cucumber_opts = "-t ~@wip -t ~@off"
+  t.cucumber_opts = "-t ~@wip -t ~@off -f progress"
 end
 
 desc 'Run all API specifications for the gem'

data/cucumber_analytics.gemspec

@@ -17,7 +17,9 @@ Gem::Specification.new do |gem|
   gem.require_paths = ['lib']
   gem.version       = CucumberAnalytics::VERSION
 
-  gem.add_runtime_dependency('gherkin')
+  gem.add_runtime_dependency('gherkin', '~> 2.11.0')
+  gem.add_runtime_dependency('json', '~> 1.0')
+  gem.add_runtime_dependency('multi_json', '~> 1.0')
 
   gem.add_development_dependency('rake')
   gem.add_development_dependency('cucumber')

data/features/modeling/background_modeling.feature

@@ -3,21 +3,27 @@ Feature: Background elements can be modeled.
 
   Acceptance criteria
 
-  All conceptual pieces of a Background can be modeled:
-    1. the background's name
-    2. the background's description
-    3. the background's steps
-    4. the background's source line
-    5. the background's raw element
+    1. All conceptual pieces of a background can be modeled:
+      - the background's name
+      - the background's description
+      - the background's steps
+      - the background's source line
+      - the background's raw element
 
+    2. Backgrounds can be outputted in a convenient form
+
+  
   Background: Test file setup.
     Given the following feature file:
     """
     Feature:
 
-      Background:Some general test setup stuff.
-          Some background description
-          Some more description
+      Background: Some general test setup stuff.
+            
+        Some background description.
+    
+      Some more.
+          Even more.
 
         Given a setup step
         And another setup step
@@ -39,9 +45,14 @@ Feature: Background elements can be modeled.
       | name | Some general test setup stuff. |
 
   Scenario: The background description is modeled.
-    Then the background's descriptive lines are as follows:
-      | Some background description |
-      | Some more description       |
+    Then the background has the following description:
+      """
+          
+      Some background description.
+
+      Some more.
+        Even more.
+      """
 
   Scenario: The background steps are modeled.
     Then the background's steps are as follows:
@@ -49,8 +60,11 @@ Feature: Background elements can be modeled.
       | another setup step |
       | an action step     |
 
+  Scenario: Convenient output of a background
+    Then the background has convenient output
+
   Scenario Outline: Background models pass all other specifications
-  Exact specifications detailing the API for Background models.
+  Exact specifications detailing the API for background models.
     Given that there are "<additional specifications>" detailing models
     When the corresponding specifications are run
     Then all of those specifications are met

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

@@ -3,11 +3,13 @@ Feature: Directories can be modeled.
 
   Acceptance criteria
 
-  Directories containing feature files can be modeled:
-    1. the directory's name
-    2. the directory's full path
-    3. all feature files contained
-    4. all directories contained
+    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
@@ -69,7 +71,7 @@ Feature: Directories can be modeled.
     When the directory "feature_directory" is read
     And the directory "feature_directory/nested_directory" is read
 
-  Scenario: The directory's name is  modeled.
+  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:
@@ -103,6 +105,9 @@ Feature: Directories can be modeled.
       | directory_count | 0 |
     And directory "2" has no directories
 
+  Scenario: Convenient output of a directory
+    Then the directory has convenient output
+
   Scenario Outline: Directory models pass all other specifications
   Exact specifications detailing the API for directory models.
     Given that there are "<additional specifications>" detailing models

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

@@ -1,12 +1,14 @@
-Feature: Doc String elements can be modeled.
+Feature: Doc string elements can be modeled.
 
 
   Acceptance criteria
 
-  All conceptual pieces of a Doc String can be modeled:
-    1. the doc string's content type
-    2. the doc string's contents
-    3. the doc string's raw element
+    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.
@@ -38,14 +40,19 @@ Feature: Doc String elements can be modeled.
 
   Scenario: The doc string's contents are modeled.
     Then the step "1" doc string has the following contents:
-      | 'some text'          |
-      | '  '                 |
-      | '    some more text' |
-      | ''                   |
+      """
+      some text
+        
+          some more text
+      
+      """
     And the step "2" doc string contents are empty
 
-  Scenario Outline: Doc String models pass all other specifications
-  Exact specifications detailing the API for Doc String models.
+  Scenario: Convenient output of an a doc string
+    Then the doc string has convenient output
+
+  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

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

@@ -3,15 +3,17 @@ Feature: Example elements can be modeled.
 
   Acceptance criteria
 
-  All conceptual pieces of an Examples block can be modeled:
-    1. the example's name
-    2. the example's description
-    3. the example's parameters
-    4. the example's rows
-    5. the example's tags
-    6. the example's applied tags
-    7. the example's source line
-    8. the example's raw element
+    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.
@@ -25,14 +27,16 @@ Feature: Example elements can be modeled.
         * a step
 
       Examples: text describing the significance of the examples
-          Example description
-          more description
+            
+        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
-          Description
         | param1 |
         | a      |
     """
@@ -47,7 +51,7 @@ Feature: Example elements can be 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 | 15 |
+      | source_line | 18 |
 
   Scenario: The examples' name is modeled.
     Then the test example block "1" is found to have the following properties:
@@ -56,11 +60,15 @@ Feature: Example elements can be modeled.
       | name | some examples with different significance and a tag |
 
   Scenario: The examples' description is modeled.
-    Then the test example block "1" descriptive lines are as follows:
-      | Example description |
-      | more description    |
-    And the test example block "2" descriptive lines are as follows:
-      | Description |
+    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
@@ -88,8 +96,11 @@ Feature: Example elements can be modeled.
     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
+
   Scenario Outline: Example models pass all other specifications
-  Exact specifications detailing the API for Examples models.
+  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