cuke_modeler 0.4.1 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 414503e25b096ba139b0585a57db358e5874c263
-  data.tar.gz: c982a0ae8247c086de6a8af77fef5552bc744184
+  metadata.gz: 3d45c74a6f723c171dac766c39700fe913bb5780
+  data.tar.gz: e75f758bd4197d5ba5894c1c147d8a9e8a393d0e
 SHA512:
-  metadata.gz: e3e67445b91027baa77694302656394837fce4e384cc213c4f1ba8127b5826a5d6d6c6105998030b1e429c7c71a26522df26e5cae044f0a1f62cf089aeaa7b9a
-  data.tar.gz: 499a61bbd3f475f9ad9cfb0f3f00903eaec01895b68eed7496c89404e2a1c8c4ef7fb8eda54deeaff9b49e1c8e0acc11d335fd0b54ea55c56711f55a7be034e2
+  metadata.gz: d1be16e1d99e64f661d87b22fa5efce4feb84444b7c498628ee964ef491a621c1c041b1437c1e6c265abf784bfb6ac80ee2048433402c40889be9555761c4cd4
+  data.tar.gz: f9866720e77b5d436b5e88dbeb791bc7b92384bd39ceb3c55cd201570c2868b09de93eec85f260940da0f98de32ce162b0bcb1899b9db9545b133d5041f5066e

data/.gitignore

@@ -1,17 +1,17 @@
-*.gem
-*.rbc
-.bundle
-.config
-.yardoc
-Gemfile.lock
-InstalledFiles
-_yardoc
-coverage
-doc/
-lib/bundler/man
-pkg
-rdoc
-spec/reports
-test/tmp
-test/version_tmp
-tmp
+*.gem
+*.rbc
+.bundle
+.config
+.yardoc
+Gemfile.lock
+InstalledFiles
+_yardoc
+coverage
+doc/
+lib/bundler/man
+pkg
+rdoc
+spec/reports
+test/tmp
+test/version_tmp
+tmp

data/.travis.yml

@@ -7,7 +7,7 @@ rvm:
   - 2.2.2
 
 gemfile:
-  - gemfiles/gherkin.gemfile
+  - gemfiles/gherkin2.gemfile
   - gemfiles/gherkin3.gemfile
   - gemfiles/gherkin4.gemfile
 

data/Gemfile

@@ -14,6 +14,10 @@ elsif RUBY_VERSION =~ /^1\./
   gem 'cucumber', '<2.0.0'
 end
 
+if RUBY_VERSION =~ /^1\./
+  gem 'tins', '< 1.7' # The 'tins' gem requires Ruby 2.x on/after this version
+end
+
 if RUBY_VERSION =~ /^2\./
   gem 'gherkin', '~> 4.0'
 end

data/History.rdoc

@@ -1,6 +1,71 @@
+=== Version 1.0.0 / 2016-09-08
+
+* All modeled elements of a Cucumber test suite are now modeled with actual classes. Previously, some elements (such as
+  tags or rows in an example table) were modeled with simple strings.
+
+* A base model class has been added in order to simplify adding new element models. Other classes and modules used for
+  organizing common model behavior have been created/removed/renamed.
+
+* Feature file models now only have a single feature model instead of a collection of them (that would only ever have
+  one item in it).
+
+* Rows in an example table and rows in a step table no longer use two different classes for modeling.
+
+* Background models can now be compared to other models that have steps (i.e. scenarios and outlines).
+
+* All models for Gherkin elements now track the line number from which they originate in a source file.
+
+* The source line of a model is now a mutable attribute instead of being read only.
+
+* The file path of a feature file is now a mutable attribute instead of being read only.
+
+* Standardized the initial values of the attributes of abstractly created models so that they are consistent across
+  model types.
+
+* Added specific ancestor types for scenario, outline, and background models as alternatives to the generic 'test'
+  ancestor type.
+
+* Extra whitespace around parsed element descriptions is now trimmed away before being stored in a model.
+
+* Adding rows to examples via hashes can now be done without regard to the order of the keys in the hash. The correct
+  order can be determined by the model.
+
+* The saved parsing data that is generated by the 'gherkin' gem is no longer duplicated for each model, resulting in
+  significantly less memory usage.
+
+* String output of models has been improved. More special characters in Gherkin (e.g. vertical bars in rows) are
+  appropriately escaped in the string output of a model and several minor bugs related to using model string output as
+  the input text for new models have been fixed.
+
+* Removed the backdoor used to pass around model data during the model creation process. Model input can now only be
+  text.
+
+* Simple counting methods have been removed. Ruby's collection methods are just as easy to use directly when dealing
+  with classes that contain collections and the removal of these counting methods simplifies the codebase.
+
+* The 'World' module has been removed. The scope of this gem is to model files written in Gherkin. Concepts like
+  'step definitions' and 'hooks' are better left to libraries that include (possibly programming language specific)
+  test execution logic within their scope of concern.
+
+* Step models no longer have 'arguments' because they require the concept of step definitions, which are no longer
+  within the scope of this gem.
+
+* Removed deprecated behavior
+   - Marked
+       - Doc strings no longer use an array of strings to model their content
+       - Tables no longer use nested arrays of strings to model their rows
+       - Models that have descriptions no longer use an array of strings to model their description
+       - The convenient (read: awkward) #step_text has been removed.
+   - Unmarked
+       - Examples no longer use an array of hashes to model their rows
+
+* Various methods have been renamed.
+
+
 === Version 0.4.1 / 2016-05-12
 
-* Increased the flexibility of input when adding rows to an Example object.
+* Increased the flexibility of input when adding rows to an Example object. Non-string values can now be used as input
+  and they will be converted into strings. Original input objects are not modified.
 * Added some error checking around adding value rows to an Example object without adding a parameter row as well.
 
 
@@ -8,7 +73,7 @@
 
 * The path of a Directory object is now a changeable attribute instead of only being populated if the instance was
   given a diretory to model.
-* Bug fix - Fixed a bug that occurred if a Directory object was asked for its #name when it was created 'empty'
+* Bug fix - Fixed a bug that occurred if a Directory object was asked for its #name when it was created as 'abstract'
             instead of modeling an existing directory.
 
 
@@ -21,12 +86,15 @@
 
 === Version 0.2.0 / 2016-02-21
 
-* Better error feedback when parsing errors are encountered.
+* Better error feedback when parsing errors are encountered. It is now easier to tell which file contained invalid
+  Gherkin.
 
 
 === Version 0.1.0 / 2016-02-10
 
 * Support for version 3.x of the 'gherkin' gem added.
+* Bug fix - The saved parsing data that is generated by the 'gherkin' gem is no longer modified by the rest of the
+            model creation process.
 
 
 === Version 0.0.2 / 2015-11-22

data/LICENSE.txt

@@ -1,22 +1,22 @@
-Copyright (c) 2014 Eric Kessler
-
-MIT License
-
-Permission is hereby granted, free of charge, to any person obtaining
-a copy of this software and associated documentation files (the
-"Software"), to deal in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish,
-distribute, sublicense, and/or sell copies of the Software, and to
-permit persons to whom the Software is furnished to do so, subject to
-the following conditions:
-
-The above copyright notice and this permission notice shall be
-included in all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
-NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
-LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
-OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
-WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+Copyright (c) 2014 Eric Kessler
+
+MIT License
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be
+included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

data/README.md

@@ -1,9 +1,14 @@
 # CukeModeler
 
-The intention of this gem is to provide the ability to model a Cucumber test
-suite. It provides a foundation upon which to build other useful tools for
-interacting with a test suite that is written in Gherkin (and written with
-Cucumber in particular).
+There comes a time in every programmer's adventures with Cucumber when they want to do Really Cool 
+Stuff with their tests. This usually necessitates scanning all of their feature files and playing 
+with the output. While the **[gherkin](https://github.com/cucumber/gherkin)** gem does a fine job of parsing feature files, reading or even 
+manipulating the resulting Abstract Syntax Tree is not always fun. **cuke_modeler** comes to the 
+rescue by providing a modeling layer that is easier to work with.
+ 
+Whether you just want something that will let you easily inspect your test suite or you are looking 
+for a foundation tool upon which to build something Really Neat, this gem has you covered.
+
 
 ## Installation
 
@@ -23,7 +28,7 @@ Or install it yourself as:
 
 First, load up the gem code.
 
-  require 'cuke_modeler'
+    require 'cuke_modeler'
 
 Next, choose what you want to model. Directories and feature files are the most
 common thing to model but smaller portions of a test suite can be modeled as well.
@@ -46,7 +51,7 @@ and setting their attributes afterward.
 
     step = CukeModeler::Step.new
     step.keyword = 'Given'
-    step.base = 'some step'
+    step.text = 'some step'
 
     test = CukeModeler::Scenario.new
     test.steps = [step]
@@ -54,7 +59,15 @@ and setting their attributes afterward.
     test.to_s #=> "Scenario:\n  Given some step"
 
 One could, if so inclined, use this method to dynamically edit or even create an
-entire test suite.
+entire test suite!
+
+
+## Modeling other versions of Cucumber
+
+Although this gem is written in Ruby and requires it to run, the modeling capabilities provided are for 
+the feature file layer of a Cucumber test suite. As such, any feature file that is written in Gherkin can 
+be modeled, even if that feature is ultimately run with SpecFlow (Cucumber for C#), Lettuce (Cucumber for 
+Python), or some other flavor of Cucumber. 
 
 
 ### Other gems that are (or soon will be) powered by cuke_modeler
@@ -64,10 +77,11 @@ entire test suite.
   * https://github.com/enkessler/cuke_cataloger
   * https://github.com/grange-insurance/cuke_slicer
 
+
 ## Contributing
 
 1. Fork it
-2. Create your feature branch (`git checkout -b my-new-feature`)
-3. Commit your changes (`git commit -am 'Add some feature'`)
-4. Push to the branch (`git push origin my-new-feature`)
+2. Create your feature branch (off of the development branch):  `git checkout -b my-new-feature`
+3. Commit your changes:  `git commit -am 'Add some feature'`
+4. Push to the branch:  `git push origin my-new-feature`
 5. Create new Pull Request

data/Rakefile

@@ -25,18 +25,8 @@ namespace 'cuke_modeler' do
 
   desc 'Test gem based on Ruby/dependency versions'
   task :smart_test do |t, args|
-    rspec_args = ''
-
-    case
-      when Gem.loaded_specs['gherkin'].version.version[/^4/]
-        cucumber_args = '-t ~@gherkin -t ~@gherkin3'
-      when Gem.loaded_specs['gherkin'].version.version[/^3/]
-        cucumber_args = '-t ~@gherkin -t ~@gherkin4'
-      else
-        cucumber_args = '-t ~@gherkin3 -t ~@gherkin4'
-    end
-
-    cucumber_args += ' -f progress'
+    rspec_args = '--tag ~@wip'
+    cucumber_args = '-f progress -t ~@wip'
 
     Rake::Task['cuke_modeler:test_everything'].invoke(rspec_args, cucumber_args)
   end

data/cuke_modeler.gemspec

@@ -24,7 +24,7 @@ Gem::Specification.new do |spec|
   spec.add_development_dependency "bundler", "~> 1.5"
   spec.add_development_dependency "rake"
   spec.add_development_dependency 'cucumber'
-  spec.add_development_dependency 'rspec', '~> 2.14.0'
+  spec.add_development_dependency 'rspec', '~> 3.0'
   spec.add_development_dependency 'simplecov'
   spec.add_development_dependency 'racatt', '~> 1.0'
   spec.add_development_dependency 'coveralls'

data/features/analysis/test_comparison.feature

@@ -1,123 +1,38 @@
-Feature: Test equality can be determined.
-
-
-  Acceptance criteria
-
-  Tests can be compared for equality.
-    1. tests whose steps are the same except for arguments and keywords (i.e.
-       they match the same step definition) are equal
-
-
-  Background: Test file setup.
-    Given the following feature file:
-    """
-    Feature: A feature with duplicate tests.
-
-      Scenario: A test
-        Given this *parameterized* step takes a table:
-          | data 1 |
-          | data 2 |
-        And some setup step
-        When a step with a *parameter*
-        And a big step:
-        \"\"\"
-        little doc block
-        \"\"\"
-        Then *lots* *of* *parameters*
-
-      Scenario: Same test, different arguments and keywords
-        Given this *similarly parameterized* step takes a table:
-          | data 3 |
-          | data 4 |
-        Given some setup step
-        When a step with a *parameter*
-        * a big step:
-        \"\"\"
-        A little
-        bigger doc block
-        \"\"\"
-        Then *lots* *of* *parameters*
-
-      Scenario Outline: This is the same test as an outline
-        Given this *parameterized* step takes a table:
-          | <param1> |
-          | <param2> |
-        And some setup step
-        When a step with a *parameter*
-        And a big step:
-        \"\"\"
-        little doc block
-        \"\"\"
-        Then *lots* *of* *parameters*
-      Examples:
-        | param1 | param2 |
-        | x      | y      |
-      Examples:
-        | param1 | param2 |
-        | a      | b      |
-
-      Scenario Outline: Same outline, different arguments and keywords
-        Given this *similarly parameterized* step takes a table:
-          | <param3> |
-          | <param4> |
-        Given some setup step
-        When a step with a *slightly different parameter*
-        * a big step:
-        \"\"\"
-        A little
-        bigger doc block
-        \"\"\"
-        Then *lots* *of effectively the same* *parameters*
-      Examples:
-        | param1 | param2 |
-        | h      | k      |
-      Examples:
-        | param1 | param2 |
-        | i      | j      |
-
-      Scenario: A different test
-        Given this *parameterized* step takes a table:
-          | data 1 |
-          | data 2 |
-        And not the same setup step as before
-        When a step with a *parameter*
-        And a big step:
-        \"\"\"
-        little doc block
-        \"\"\"
-        Then *lots* *of* *parameters*
-
-      Scenario Outline: This is the same different test as an outline
-        Given this *similarly parameterized* step takes a table:
-          | <param1> |
-          | <param2> |
-        And not the same setup step as before
-        When a step with a *slightly different parameter*
-        And a big step:
-        \"\"\"
-        A little
-        bigger doc block
-        \"\"\"
-        Then *lots* *of effectively the same* *parameters*
+Feature: Test comparison
+
+  Gherkin elements that contain steps (i.e. backgrounds, scenarios, and outlines) can be compared with one another
+  in order to determine equality. Elements are considered equal if the base text of their steps match. That is, the
+  keyword used for the step and any table or doc string that may be associated with that step are ignored for the
+  purposes of comparison.
+
+
+  Scenario: Comparing tests
+    Given a model for the following background:
+      """
+      Background:
+        * step 1
+        * step 2
+      """
+    And a model for the following scenario:
+      """
+      Scenario:
+        * step 1
+        * step 2
+      """
+    And a model for the following outline:
+      """
+      Scenario Outline:
+        * step 1
+        * step 2
       Examples:
-        | param1 | param2 |
-        | x      | y      |
-      Examples:
-        | param1 | param2 |
-        | a      | b      |
-    """
-    And parameter delimiters of "*" and "*"
-    When the file is read
-
-
-  Scenario: Scenario to Scenario comparison
-    Then test "1" is equal to test "2"
-    And test "1" is not equal to test "5"
-
-  Scenario: Outline to Outline comparison
-    Then test "3" is equal to test "4"
-    And test "3" is not equal to test "6"
-
-  Scenario: Scenario to Outline comparison
-    Then test "1" is equal to test "3"
-    And test "1" is not equal to test "6"
+        | param |
+        | value |
+      """
+    When the models are compared
+    Then all of them are equivalent
+    But none of the models are equivalent with a model for the following scenario:
+      """
+      Scenario:
+        * step 1
+        * step 3
+      """