cuke_modeler 0.0.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 876bbe0bbe75f460596777b28b51a51bd3347c01
+  data.tar.gz: 5ee73b6f5366259721f57dbca7ca7120b9497243
+SHA512:
+  metadata.gz: f8b1099a66acacf4442cc6d5a64f61ae52762727fe8f70279a6049b450de56b49335b502ec7ecbc84395404ac0081df7792a6de6a2b6f6e7c1bbcb361e590a36
+  data.tar.gz: 387d74e18f8be3cd4b028f8f2d1e79660ee67041636f701af58601bf660b9731e97ed5482e4c91add71f8f33856b05274e785dacd79c5a19d6e4a4f9749b2bf6

data/.gitignore

@@ -0,0 +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

data/.simplecov

@@ -0,0 +1,8 @@
+SimpleCov.start do
+  root File.dirname(__FILE__)
+
+  add_filter '/features/'
+  add_filter '/spec/'
+
+  merge_timeout 300
+end

data/Gemfile

@@ -0,0 +1,4 @@
+source 'https://rubygems.org'
+
+# Specify your gem's dependencies in cuke_modeler.gemspec
+gemspec

data/History.rdoc

@@ -0,0 +1,3 @@
+=== Version 0.0.1 / 2014-06-02
+
+* Initial release

data/LICENSE.txt

@@ -0,0 +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.

data/README.md

@@ -0,0 +1,73 @@
+# 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).
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+    gem 'cuke_modeler'
+
+And then execute:
+
+    $ bundle
+
+Or install it yourself as:
+
+    $ gem install cuke_modeler
+
+## Usage
+
+First, load up the gem code.
+
+  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.
+
+    directory = CukeModeler::Directory.new('path/to/the/code_directory')
+    file = CukeModeler::FeatureFile.new('path/to/the/feature_file')
+
+    gherkin = "Scenario: some test\n* a step"
+    test = CukeModeler::Scenario.new(gherkin)
+
+The models can then be inspected for information.
+
+    directory.path #=> 'path/to/the/code_directory'
+    file.feature.name #=> 'the name of the feature'
+    test.steps.count #=> 1
+
+
+Things can be done in the other direction as well by starting with empty models
+and setting their attributes afterward.
+
+    step = CukeModeler::Step.new
+    step.keyword = 'Given'
+    step.base = 'some step'
+
+    test = CukeModeler::Scenario.new
+    test.steps = [step]
+
+    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.
+
+
+### Other gems that are (or soon will be) powered by cuke_modeler
+
+https://github.com/enkessler/cucumber_analytics
+https://github.com/enkessler/cql
+https://github.com/enkessler/cuketagger
+https://github.com/enkessler/cuke_cataloger
+
+## 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`)
+5. Create new Pull Request

data/Rakefile

@@ -0,0 +1,38 @@
+require "bundler/gem_tasks"
+require 'cucumber/rake/task'
+require 'rspec/core/rake_task'
+
+
+def set_cucumber_options(options)
+  ENV['CUCUMBER_OPTS'] = options
+end
+
+def combine_options(set_1, set_2)
+  set_2 ? "#{set_1} #{set_2}" : set_1
+end
+
+
+task :clear_coverage do
+  code_coverage_directory = "#{File.dirname(__FILE__)}/coverage"
+
+  FileUtils.remove_dir(code_coverage_directory, true)
+end
+
+desc 'Run all Cucumber tests for the gem'
+task :tests, [:options] do |t, args|
+  set_cucumber_options(combine_options("-t ~@wip -t ~@off -f progress", args[:options]))
+end
+Cucumber::Rake::Task.new(:tests)
+
+desc 'Run all RSpec tests for the gem'
+RSpec::Core::RakeTask.new(:specs) do |t|
+  t.rspec_opts = "-t ~wip -t ~off"
+end
+
+desc 'Run All The Things'
+task :everything => :clear_coverage do
+  Rake::Task[:specs].invoke
+  Rake::Task[:tests].invoke('-t ~@redundant')
+end
+
+task :default => :everything

data/cuke_modeler.gemspec

@@ -0,0 +1,29 @@
+# coding: utf-8
+lib = File.expand_path('../lib', __FILE__)
+$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
+require 'cuke_modeler/version'
+
+Gem::Specification.new do |spec|
+  spec.name          = "cuke_modeler"
+  spec.version       = CukeModeler::VERSION
+  spec.authors       = ["Eric Kessler"]
+  spec.email         = ["morrow748@gmail.com"]
+  spec.summary       = %q{A gem providing functionality to model a Cucumber test suite.}
+  spec.homepage      = 'https://github.com/enkessler/cuke_modeler'
+  spec.license       = "MIT"
+
+  spec.files         = `git ls-files -z`.split("\x0")
+  spec.executables   = spec.files.grep(%r{^bin/}) { |f| File.basename(f) }
+  spec.test_files    = spec.files.grep(%r{^(test|spec|features)/})
+  spec.require_paths = ["lib"]
+
+  spec.add_runtime_dependency('gherkin')
+  spec.add_runtime_dependency('json', '~> 1.0')
+  spec.add_runtime_dependency('multi_json', '~> 1.0')
+
+  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 'simplecov'
+end

data/features/analysis/test_comparison.feature

@@ -0,0 +1,123 @@
+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*
+      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"

data/features/analysis/test_manipulation.feature

@@ -0,0 +1,37 @@
+Feature: Tests can be manipulated in various ways.
+
+
+  Acceptance criteria
+
+  Tests can be manipulated:
+    1. outlines can have rows added and removed
+
+
+  Background: Test file setup.
+    Given the following feature file:
+    """
+    Feature: A feature containing our starting outline.
+
+      Scenario Outline:
+        Given this *parameterized* step takes a table:
+          | <param1> |
+          | <param2> |
+        Then I don't really need another step
+      Examples: Only one row to start with
+        | param1 | param2 |
+        | x      | y      |
+    """
+    And parameter delimiters of "*" and "*"
+    And the file is read
+
+  Scenario: Rows can be added to an outline
+    When the test example block has the following rows added to it:
+      | 1,2 |
+    Then the test example block rows are as follows:
+      | x,y |
+      | 1,2 |
+
+  Scenario: Rows can be removed from an outline
+    When the test example block has the following rows removed from it:
+      | x,y |
+    Then the test example block has no rows

data/features/modeling/background_modeling.feature

@@ -0,0 +1,75 @@
+Feature: Background elements can be modeled.
+
+
+  Acceptance criteria
+
+    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.
+          Even more.
+
+        Given a setup step
+        And another setup step
+        When an action step
+    """
+    And parameter delimiters of "*" and "*"
+    When the file is read
+
+
+  Scenario: The raw background element is modeled.
+    Then the background correctly stores its underlying implementation
+
+  Scenario: The background source line is modeled.
+    Then the background is found to have the following properties:
+      | source_line | 3 |
+
+  Scenario: The background name is modeled.
+    Then the background is found to have the following properties:
+      | name | Some general test setup stuff. |
+
+  Scenario: The background description is modeled.
+    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:
+      | a setup step       |
+      | another setup step |
+      | an action step     |
+
+  Scenario: Convenient output of a background
+    Then the background has convenient output
+
+  @redundant
+  Scenario Outline: Background models pass all other specifications
+  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
+  Examples:
+    | additional specifications      |
+    | background_unit_spec.rb        |
+    | background_integration_spec.rb |