cucumber_analytics 0.0.9 → 1.0.0

checksums.yaml

@@ -0,0 +1,15 @@
+---
+!binary "U0hBMQ==":
+  metadata.gz: !binary |-
+    ZDdiMjBmYjRjNzY3ODM2MDNlYzQzNDRhZmZjOWM4YmI0MTQ1ZDFmZg==
+  data.tar.gz: !binary |-
+    MTAyOTE4MzQzYjUyMjM1MDY1NmYzMjBiYzg1OTE0NWViMjQ3NzAxMQ==
+!binary "U0hBNTEy":
+  metadata.gz: !binary |-
+    YmE1OWU5N2QwNzRjZjQ2NzExN2NlM2Q3ZGQ2NjY5YjlkMWE3M2JiODgyNmNh
+    MjQ4NTQ0ZmUwMWNjZmQwNWM0ODNlMjdiZTJjMGY3MjdmZGY1M2Y3ZTQ3YmIw
+    MzkxNThhZmJjMjcwZmVlOTc2ODhmYWRlMThlNDUzNGY0ZTI4ZjU=
+  data.tar.gz: !binary |-
+    NTBlYmU2MDAwNWUwMjA0MDRkZDdiMGY4NDk3MWU4YjYyNjkwYjYyZjc2YzJl
+    NDRmYTExZWYzY2U0YmI5MTZiYTRkNDNlYjg3MDUxNTJiZThjNGJlOWU2MDFl
+    MzdmZjJmMzUzOGYwY2U0MjlkODIwZGY1OTM0NzEzYjk0ZDA3NzQ=

data/History.rdoc

@@ -1,3 +1,19 @@
+=== Version 1.0.0 / 2013-06-30
+
+* Bug fix: Step definitions are now detected whether or not parenthesis are
+  used in the declararion.
+* Now using the gherkin gem to parse feature files. This should eliminate most
+  parsing related bugs.
+* Empty outline example blocks can non longer be handeled (since the gherkin gem
+  can likewise not handle them).
+* Source code snippets can now be analyzed (rather than needing an entire feature
+  file to parse).
+* Logging has been removed from the gem due to its significant negative impact
+  on performance.
+* Many class and method names have changed.
+* Significant API overhaul, including several new classes for modeling.
+
+
 === Version 0.0.9 / 2013-02-25
 
 * Bug fix: Fixed an un-anchored regular expression that was causing

data/README.rdoc

@@ -39,7 +39,7 @@ First things first. Load up the gem code.
 
 Next, let's generate a model for our Cucumber suite.
 
-  directory = CucumberAnalytics::ParsedDirectory.new('path/to/the/code_directory')
+  directory = CucumberAnalytics::Directory.new('path/to/the/code_directory')
   world = CucumberAnalytics::World
 
 Now it's time to take a look around and see what we can see.
@@ -58,8 +58,8 @@ Now it's time to take a look around and see what we can see.
 
 
   all_steps = world.steps_in(directory)
-  puts all_steps.collect{ |step| step.step_text(:with_keywords => false)}
-  #=> ["some step", "the user logs in", "the user will log in", "another step", "the user "Bob" logs in"]
+  puts all_steps.collect{ |step| step.base}
+  #=> ["some step", "the user logs in", "the user will log in", "another step", "the user \"Bob\" logs in"]
 
 So with a few simple commands we have discovered that there are five different
 tags in our codebase and that @wip tags account for half of all usages. We have
@@ -74,3 +74,5 @@ rewritten into a single, reusable step.
 3. Commit your changes (`git commit -am 'Added some feature'`)
 4. Push to the branch (`git push origin my-new-feature`)
 5. Create new Pull Request
+
+I'm always looking for new ways to poke at a testbase. Feature requests are welcome.

data/Rakefile

@@ -4,11 +4,16 @@ require 'cucumber/rake/task'
 require 'rspec/core/rake_task'
 
 
-
 desc 'Run all acceptance tests for the gem'
 Cucumber::Rake::Task.new(:tests)
 
 desc 'Run all API specifications for the gem'
 RSpec::Core::RakeTask.new(:specs)
 
-task :default => :tests
+desc 'Run All The Things'
+task :everything do
+  Rake::Task[:specs].invoke
+  Rake::Task[:tests].invoke
+end
+
+task :default => :everything

data/cucumber_analytics.gemspec

@@ -2,19 +2,21 @@
 require File.expand_path('../lib/cucumber_analytics/version', __FILE__)
 
 Gem::Specification.new do |gem|
-  gem.authors       = ["Eric Kessler"]
-  gem.email         = ["morrow748@gmail.com"]
+  gem.authors       = ['Eric Kessler']
+  gem.email         = ['morrow748@gmail.com']
   gem.description   = %q{Static analysis of Cucumber tests made easy.}
   gem.summary       = %q{This gem provides an API to programmatically break down Cucumber feature files so that they can be inspected and analyzed in a straightforward manner.}
-  gem.homepage      = "https://github.com/enkessler/cucumber_analytics"
+  gem.homepage      = 'https://github.com/enkessler/cucumber_analytics'
 
   gem.files         = `git ls-files`.split($\)
   gem.executables   = gem.files.grep(%r{^bin/}).map{ |f| File.basename(f) }
   gem.test_files    = gem.files.grep(%r{^(test|spec|features)/})
-  gem.name          = "cucumber_analytics"
-  gem.require_paths = ["lib"]
+  gem.name          = 'cucumber_analytics'
+  gem.require_paths = ['lib']
   gem.version       = CucumberAnalytics::VERSION
 
+  gem.add_runtime_dependency('gherkin')
+
   gem.add_development_dependency('rake')
   gem.add_development_dependency('cucumber')
   gem.add_development_dependency('rspec')

data/features/analysis/step_collection.feature

@@ -61,77 +61,76 @@ Feature: Steps can be collected from arbitrary parts of the codebase.
     And the directory "feature_directory" is read
 
 
-
   Scenario: Steps can be collected from backgrounds
     Then the steps collected from feature "1" background are as follows:
-      | Given a defined step  |
-      | And an undefined step |
+      | a defined step    |
+      | an undefined step |
     And the "defined" steps collected from feature "1" background are as follows:
-      | Given a defined step |
+      | a defined step |
     And the "undefined" steps collected from feature "1" background are as follows:
-      | And an undefined step |
+      | an undefined step |
 
   Scenario: Steps can be collected from scenarios
     Then the steps collected from feature "1" test "1" are as follows:
-      | Given another defined step  |
-      | Then another undefined step |
+      | another defined step   |
+      | another undefined step |
     And the "defined" steps collected from feature "1" test "1" are as follows:
-      | Given another defined step |
+      | another defined step |
     And the "undefined" steps collected from feature "1" test "1" are as follows:
-      | Then another undefined step |
+      | another undefined step |
 
   Scenario: Steps can be collected from scenario outlines
     Then the steps collected from feature "2" test "1" are as follows:
-      | Given a defined step                  |
-      | When another defined step             |
-      | Then *<this>* *step is* *<undefined>* |
+      | a defined step                   |
+      | another defined step             |
+      | *<this>* *step is* *<undefined>* |
     And the "defined" steps collected from feature "2" test "1" are as follows:
-      | Given a defined step      |
-      | When another defined step |
+      | a defined step       |
+      | another defined step |
     And the "undefined" steps collected from feature "2" test "1" are as follows:
-      | Then *<this>* *step is* *<undefined>* |
+      | *<this>* *step is* *<undefined>* |
 
   Scenario: Steps can be collected from features
     Then the steps collected from feature "1" are as follows:
-      | Given a defined step        |
-      | And an undefined step       |
-      | Given another defined step  |
-      | Then another undefined step |
+      | a defined step         |
+      | an undefined step      |
+      | another defined step   |
+      | another undefined step |
     And the "defined" steps collected from feature "1" are as follows:
-      | Given a defined step       |
-      | Given another defined step |
+      | a defined step       |
+      | another defined step |
     And the "undefined" steps collected from feature "1" are as follows:
-      | And an undefined step       |
-      | Then another undefined step |
+      | an undefined step      |
+      | another undefined step |
 
   Scenario: Steps can be collected from files
     Then the steps collected from file "1" are as follows:
-      | Given a defined step        |
-      | And an undefined step       |
-      | Given another defined step  |
-      | Then another undefined step |
+      | a defined step         |
+      | an undefined step      |
+      | another defined step   |
+      | another undefined step |
     And the "defined" steps collected from file "1" are as follows:
-      | Given a defined step       |
-      | Given another defined step |
+      | a defined step       |
+      | another defined step |
     And the "undefined" steps collected from file "1" are as follows:
-      | And an undefined step       |
-      | Then another undefined step |
+      | an undefined step      |
+      | another undefined step |
 
   Scenario: Steps can be collected from directories
     Then the steps collected from the directory are as follows:
-      | Given a defined step                  |
-      | And an undefined step                 |
-      | Given another defined step            |
-      | Then another undefined step           |
-      | Given a defined step                  |
-      | When another defined step             |
-      | Then *<this>* *step is* *<undefined>* |
+      | a defined step                   |
+      | an undefined step                |
+      | another defined step             |
+      | another undefined step           |
+      | a defined step                   |
+      | another defined step             |
+      | *<this>* *step is* *<undefined>* |
     And the "defined" steps collected from the directory are as follows:
-      | Given a defined step       |
-      | Given another defined step |
-      | Given a defined step       |
-      | When another defined step  |
+      | a defined step       |
+      | another defined step |
+      | a defined step       |
+      | another defined step |
     And the "undefined" steps collected from the directory are as follows:
-      | And an undefined step                 |
-      | Then another undefined step           |
-      | Then *<this>* *step is* *<undefined>* |
+      | an undefined step                |
+      | another undefined step           |
+      | *<this>* *step is* *<undefined>* |

data/features/modeling/background_modeling.feature

@@ -11,55 +11,15 @@ Feature: Background elements can be modeled.
   Background: Test file setup.
     Given the following feature file:
     """
-    Feature: The test feature name.
-      Some more feature description.
+    Feature:
 
       Background:Some general test setup stuff.
-       My big hunk of perfectly valid description:
-          |
+          Some background description
+          Some more description
 
-          Scenario Outline
-          Examples
-          \"\"\"
-          Background
-           this is still one big valid description
-          # Basically, if it's not a step keyword or tag then I will accept
-          # it as description here. Cucumber might not but but that's between
-          # you and its lexxer/parser. ;)
-        Given this *parameterized* step takes a table:
-          | data      |
-          | more data |
-        When some setup step
-        But some setup step
-#
-        Then a step with a *parameter*
-        And some big setup step:
-        #random comment
-        \"\"\"
-      some text
-
-        #some comments
-        Scenario:
-        Scenario Outline:
-        Examples:
-        @
-        Feature:
-        |
-        Given
-        When
-        Then
-        And
-        But
-        *
-            some more text
-        \"\"\"
-        * *lots* *of* *parameters*
-
-
-      Scenario: The first scenario's name.
-        Given the first step
-        When the second step
-        Then the third step
+        Given a setup step
+        And another setup step
+        When an action step
     """
     And parameter delimiters of "*" and "*"
     When the file is read
@@ -71,105 +31,14 @@ Feature: Background elements can be modeled.
 
   Scenario: The background description is modeled.
     Then the background's descriptive lines are as follows:
-      | My big hunk of perfectly valid description:                       |
-      | \|                                                                |
-      | Scenario Outline                                                  |
-      | Examples                                                          |
-      | """                                                               |
-      | Background                                                        |
-      | this is still one big valid description                           |
+      | Some background description |
+      | Some more description       |
 
   Scenario: The background steps are modeled.
     Then the background's steps are as follows:
-      | Given this *parameterized* step takes a table: |
-      | \| data      \|                                |
-      | \| more data \|                                |
-      | When some setup step                           |
-      | But some setup step                            |
-      | Then a step with a *parameter*                 |
-      | And some big setup step:                       |
-      | """                                            |
-      | 'some text'                                    |
-      | ''                                             |
-      | '#some comments'                               |
-      | 'Scenario:'                                    |
-      | 'Scenario Outline:'                            |
-      | 'Examples:'                                    |
-      | '@'                                            |
-      | 'Feature:'                                     |
-      | '\|'                                           |
-      | 'Given'                                        |
-      | 'When'                                         |
-      | 'Then'                                         |
-      | 'And'                                          |
-      | 'But'                                          |
-      | '*'                                            |
-      | '    some more text'                           |
-      | """                                            |
-      | * *lots* *of* *parameters*                     |
-    And the background's steps "without" arguments are as follows:
-      | Given this ** step takes a table: |
-      | When some setup step              |
-      | But some setup step               |
-      | Then a step with a **             |
-      | And some big setup step:          |
-      | * ** ** **                        |
-    And the background's steps "without" keywords are as follows:
-      | this *parameterized* step takes a table: |
-      | \| data      \|                          |
-      | \| more data \|                          |
-      | some setup step                          |
-      | some setup step                          |
-      | a step with a *parameter*                |
-      | some big setup step:                     |
-      | """                                      |
-      | 'some text'                              |
-      | ''                                       |
-      | '#some comments'                         |
-      | 'Scenario:'                              |
-      | 'Scenario Outline:'                      |
-      | 'Examples:'                              |
-      | '@'                                      |
-      | 'Feature:'                               |
-      | '\|'                                     |
-      | 'Given'                                  |
-      | 'When'                                   |
-      | 'Then'                                   |
-      | 'And'                                    |
-      | 'But'                                    |
-      | '*'                                      |
-      | '    some more text'                     |
-      | """                                      |
-      | *lots* *of* *parameters*                 |
-    And the background's steps "without" arguments "without" keywords are as follows:
-      | this ** step takes a table: |
-      | some setup step             |
-      | some setup step             |
-      | a step with a **            |
-      | some big setup step:        |
-      | ** ** **                    |
-    And step "1" of the background has the following block:
-      | \| data      \| |
-      | \| more data \| |
-    And step "5" of the background has the following block:
-      | """                  |
-      | 'some text'          |
-      | ''                   |
-      | '#some comments'     |
-      | 'Scenario:'          |
-      | 'Scenario Outline:'  |
-      | 'Examples:'          |
-      | '@'                  |
-      | 'Feature:'           |
-      | '\|'                 |
-      | 'Given'              |
-      | 'When'               |
-      | 'Then'               |
-      | 'And'                |
-      | 'But'                |
-      | '*'                  |
-      | '    some more text' |
-      | """                  |
+      | a setup step       |
+      | another setup step |
+      | an action step     |
 
   Scenario Outline: Background models pass all other specifications
   Exact specifications detailing the API for Background models.
@@ -177,5 +46,6 @@ Feature: Background elements can be modeled.
     When the corresponding unit tests are run
     Then all of those specifications are met
   Examples:
-    | additional specifications |
-    | background_spec.rb        |
+    | additional specifications      |
+    | background_unit_spec.rb        |
+    | background_integration_spec.rb |

data/features/modeling/directory_modeling.feature

@@ -109,5 +109,6 @@ Feature: Directories can be modeled.
     When the corresponding unit tests are run
     Then all of those specifications are met
   Examples:
-    | additional specifications |
-    | directory_spec.rb         |
+    | additional specifications     |
+    | directory_unit_spec.rb        |
+    | directory_integration_spec.rb |

data/features/modeling/doc_string_modeling.feature

@@ -0,0 +1,46 @@
+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
+
+
+  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 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 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 unit tests are run
+    Then all of those specifications are met
+  Examples:
+    | additional specifications |
+    | doc_string_unit_spec.rb   |

data/features/modeling/example_modeling.feature

@@ -16,36 +16,23 @@ Feature: Example elements can be modeled.
     Given the following feature file:
     """
     @a_feature_level_tag
-    Feature: The test feature name.
+    Feature:
 
       @outline_tag
-      Scenario Outline: The scenario outline's name.
-        Given this *parameterized* step takes a table:
-          | <param1> |
-          | <param2> |
-        Then I don't really need another step
+      Scenario Outline:
+        * a step
 
-      Examples:text describing the significance of the examples
-          Anything besides the | that starts a row should be valid
-          description at this point in the test. YMMV
+      Examples: text describing the significance of the examples
+          Example description
+          more description
         |param1| param2 | extra param |
-        #A more random comment
         |x     | y      |      ?      |
         |1     | 2      |      3      |
-        @example_tag @another_one
-      Examples:some examples with different significance and a tag
-
-        Words, words, words, words,
-
-         why so many words?
-         #
-
+      @example_tag @another_one
+      Examples: some examples with different significance and a tag
+          Description
         | param1 |
-        #
-
-        #
         | a      |
-      Examples:
     """
     And parameter delimiters of "*" and "*"
     When the file is read
@@ -56,25 +43,19 @@ Feature: Example elements can be modeled.
       | 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 |
-    And the test example block "3" is found to have the following properties:
-      | name |  |
-
 
   Scenario: The examples' description is modeled.
     Then the test example block "1" descriptive lines are as follows:
-      | Anything besides the \| that starts a row should be valid |
-      | description at this point in the test. YMMV               |
+      | Example description |
+      | more description    |
     And the test example block "2" descriptive lines are as follows:
-      | Words, words, words, words, |
-      | why so many words?          |
-    And the test example block "3" has no descriptive lines
+      | 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 |
-    And the test example block "3" has no tags
 
   Scenario: The examples' applied tags are modeled.
     Then the test example block "2" is found to have the following applied tags:
@@ -88,7 +69,6 @@ Feature: Example elements can be modeled.
       | extra param |
     And the test example block "2" parameters are as follows:
       | param1 |
-    And the test example block "3" has no parameters
 
   Scenario: The examples' rows are modeled.
     Then the test example block "1" rows are as follows:
@@ -96,7 +76,6 @@ Feature: Example elements can be modeled.
       | 1,2,3 |
     And the test example block "2" rows are as follows:
       | a |
-    And the test example block "3" has no rows
 
   Scenario Outline: Example models pass all other specifications
   Exact specifications detailing the API for Examples models.
@@ -105,4 +84,4 @@ Feature: Example elements can be modeled.
     Then all of those specifications are met
   Examples:
     | additional specifications |
-    | example_spec.rb          |
+    | example_unit_spec.rb      |

data/features/modeling/feature_file_modeling.feature

@@ -53,5 +53,6 @@ Feature: Feature files can be modeled.
     When the corresponding unit tests are run
     Then all of those specifications are met
   Examples:
-    | additional specifications |
-    | file_spec.rb              |
+    | additional specifications        |
+    | feature_file_unit_spec.rb        |
+    | feature_file_integration_spec.rb |