cellophane 0.1.1 → 0.1.2

data/README.textile

@@ -6,32 +6,65 @@ h3. Installation
 
 @gem install cellophane@
 
-h3. History
+h3. Configuration
 
-By default, Cucumber expects features to live in @features@ and step definitions to live in @features/step_definitions@. When running a feature, all step definitions are loaded unless you explicitly require just the ones you want. If you structure your project differently, you have to require files explicitly, which gets old real fast.
+h4. Project-specific File
 
-After some experimenting with different directory structures, I settled on the following for my own projects:
+Cellophane can be configured project by project through the use of a @.cellophane.yaml@ file that lives in the root of your project. Configurable options are:
 
-<pre>
-my_project
-	- app
-	- config
-	- cuke
-		- features
-		- steps
-		- support
-	- db
-	- lib
-	- etc, etc
-</pre>
+*Directive*
+@cuke_command@
 
-It's based on the structure of the @spec@ directory and I find that it fits my brain pretty well. There are three organizational strategies that I found myself following:
+*Explanation*
+Tells Cellophane how to call Cucumber. Defaults to @cucumber@.
 
-# separation of features in subdirectories
-# keeping feature specific steps in files that are named according to the feature
-# keeping all shared steps in files that are named in a more generalized fashion
+*Examples*
+@cuke_command: bundle exec cucumber@
+@cuke_command: script/cucumber@
+@cuke_command: cuke@ (as in a shell alias)
 
-For example, a project my look like this:
+*Directive*
+@cucumber@
+
+*Explanation*
+Options you want to pass to Cucumber by default.
+
+*Example*
+@cucumber: --format progress --no-profile@
+
+*Notes*
+Anything defined by @cucumber@ in the configuration file will be overwritten by the @-c/--cucumber@ command line switch (see below).
+
+*Directive*
+@feature_path@
+
+*Explanation*
+Root location of your feature files. Defaults @features@.
+
+*Example*
+@feature_path: cuke/features@
+
+*Notes*
+The path is relative to your project's root.
+
+*Directive*
+@step_path@
+
+*Explanation*
+Location of your step definitions. Defaults to @features/step_definitions@. It can be defined in two ways:
+
+# a path relative to the project root
+# nested in each feature directory
+
+*Examples*
+@step_path: cuke/steps@
+<pre>
+step_path:
+  nested_in: step_definition
+</pre>
+
+*Notes*
+Use the first method if your step defitions follow the structure of your features. For example:
 
 <pre>
 my_project
@@ -58,127 +91,137 @@ my_project
 	- etc, etc
 </pre>
 
-If the features in @cuke/features/admin/reports@ had any steps that were specific to them, they would live @cuke/steps/admin/reports@. Any steps that are shared between two or more features would go in files in @cuke/support@.
-
-To use this structure in Cucumber requires explicitly requiring the files/directories with every run. To run all of the features in @cuke/features/admin/reports@, I would enter the command
+Use the second method if each feature directory has its own step definitions directory:
 
 <pre>
-cucumber -r cuke/support -r cuke/steps/admin/reports cuke/features/admin/reports
+my_project
+	- app
+	- config
+	- features
+		- admin
+			- step_definitions
+		- user
+			- step_definitions
+		- visitor
+			- step_definitions
+		- support
+	- db
+	- lib
+	- etc, etc
 </pre>
 
-I got weary of doing that all the time, so I experimented with aliases and profiles, neither of which really met my needs. So I created Cellophane. With it, the same features could be as easy as:
+*Directive*
+@requires@
+
+*Explanation*
+Other directories or files that Cucumber needs to require. It is an array.
+
+*Examples*
+@requires: [cuke/support, cuke/steps/shared]@
 
 <pre>
-cellophane admin/*
+requires:
+  - cuke/support
+  - cuke/steps/shared
 </pre>
 
-As time went on, more patterns began to emerge from my workflow, and with them, Cellophane gained abilities.
+*Notes*
+@requires@ are passed to Cucumber as defined, so absolute paths are respected.
 
-h3. Configuration
+h4. Command Line
 
-Cellophane is configured by a @.cellophane.yaml@ file that lives in the root of your project. In it, you can define where your features are located, where your steps are located, any other files/directories that should be required by Cucumber, and any default options you want to pass to Cucumber. It looks like
+Cellophane has the following command line options:
 
 <pre>
-cucumber: --format progress --no-profile
-feature_path: cuke/features
-step_path: cuke/steps
-requires: [cuke/support, cuke/steps/shared]
+Usage: cellophane [options] PATTERN
+    -r, --regexp                     PATTERN is a regular expression. Default is false.
+    -t, --tags TAGS                  Tags to include/exclude.
+    -c, --cucumber OPTIONS           Options to pass to cucumber.
+    -p, --print                      Echo the command instead of calling cucumber.
+    -d, --debug                      Require ruby-debug.
+    -v, --version                    Display the version.
+    -h, --help                       Display this screen.
 </pre>
 
-This is the configuration used to support the project structure described above.
+PATTERN is the pattern of feature files that you are interested in. By default PATTERN is a glob, but by using the @-r/--regexp@ switch, you can pass a Ruby regular expression instead (no slashes necessary). When using a glob, you can specify that files matching the pattern are to be excluded by preceeding the pattern with a tilde (~). You can also combine include and exclude patterns in the same call. See below for examples.
 
-@step_path@ can be one of two values
+If you need to pass something through to Cucumber, such as a formatter, use the @-c/--cucumber@ switch. Depending on what it is you are passing through, you might need to enclose it in quotes. Do keep in mind that @-c/--cucumber@ on the command line overrides that defined in the YAML file.
 
-# a directory relative to the project root
-# a hash that indicates steps are nested under the feature directories
+@-d/--debug@ is only useful for Cellophane development and will have no effect on Cucumber.
 
-For the first, 
+h3. History
 
-<pre>
-feature_path: features
-step_path: features/step_definitions
-</pre>
+By default, Cucumber expects features to live in @features@ and step definitions to live in @features/step_definitions@. When running a feature, all step definitions are loaded unless you explicitly require just the ones you want. If you structure your project differently, you have to require files explicitly, which gets old real fast.
 
-would be used for a Cucumber default directory structure:
+After some experimenting with different directory structures, I settled on the following for my own projects:
 
 <pre>
 my_project
 	- app
 	- config
-	- features
-		- step_definitions
+	- cuke
+		- features
+		- steps
 		- support
 	- db
 	- lib
 	- etc, etc
 </pre>
 
-This is the default in Cellophane. If your cukes are structured like this, you need not do anything else and it should work.
-
-For the second style,
+It's based on the structure of the @spec@ directory and I find that it fits my brain pretty well. There are three organizational strategies that I found myself following:
 
-<pre>
-feature_path: features
-step_path:
-  nested_in: step_definitions
-</pre>
+# separation of features in subdirectories
+# keeping feature specific steps in files that are named according to the feature
+# keeping all shared steps in files that are named in a more generalized fashion
 
-would be used if you nest your step definitions under each feature subdirectory, such as:
+For example, a project my look like this:
 
 <pre>
 my_project
 	- app
 	- config
-	- features
-		- admin
-			- step_definitions
-		- user
-			- step_definitions
-		- visitor
-			- step_definitions
+	- cuke
+		- features
+			- admin
+				- reports
+				- user_maintenance
+			- user
+				- communication
+				- profile
+		- steps
+			- admin
+				- reports
+				- user_maintenance
+			- user
+				- communication
+				- profile
 		- support
 	- db
 	- lib
 	- etc, etc
 </pre>
 
-@requires@ is an array of files/directories that Cucumber should require. If this is defined:
+If the features in @cuke/features/admin/reports@ had any steps that were specific to them, they would live @cuke/steps/admin/reports@. Any steps that are shared between two or more features would go in files in @cuke/support@.
+
+To use this structure in Cucumber requires explicitly requiring the files/directories with every run. To run all of the features in @cuke/features/admin/reports@, I would enter the command
 
 <pre>
-requires: [cuke/support, /Users/me/shared/cool_library]
+cucumber -r cuke/support -r cuke/steps/admin/reports cuke/features/admin/reports
 </pre>
 
-@-r cuke/support -r /Users/me/shared/cool_library@ will be passed to Cucumber.
-
-Other configurable options:
-
-@cuke_command@ can be set to whatever command you use to invoke cucumber. By default, it is simply @cucumber@, but you could also use @bundler exec cucumber@, @script/cucumber@, or an alias you might have defined.
-
-h3. Operation
-
-Cellophane has the following command line options:
+I got weary of doing that all the time, so I experimented with aliases and profiles, neither of which really met my needs. So I created Cellophane. With it, the same features could be as easy as:
 
 <pre>
-Usage: cellophane [options] PATTERN
-    -r, --regexp                     PATTERN is a regular expression. Default is false.
-    -t, --tags TAGS                  Tags to include/exclude.
-    -c, --cucumber OPTIONS           Options to pass to cucumber.
-    -p, --print                      Echo the command instead of calling cucumber.
-    -d, --debug                      Require ruby-debug.
-    -h, --help                       Display this screen.
+cellophane admin/*
 </pre>
 
-PATTERN is the pattern of feature files that you are interested in. By default PATTERN is a glob, but by using the @-r/--regexp@ switch, you can pass a Ruby regular expression instead (no slashes necessary). When using a glob, you can specify that files matching the pattern are to be excluded by preceeding the pattern with a tilde (~). You can also combine include and exclude patterns in the same call. See below for examples.
-
-If you need to pass something through to Cucumber, such as a formatter, use the @-c/--cucumber@ switch. Depending on what it is you are passing through, you might need to enclose it in quotes. Do keep in mind that @-c/--cucumber@ on the command line overrides that defined in the YAML file.
-
-@-d/--debug@ is only useful for Cellophane development and will have no effect on Cucumber.
+As time went on, more patterns began to emerge from my workflow, and with them, Cellophane gained abilities.
 
 h3. Examples and Notes
 
 h4. Features
 
-Feature path is relative to the project root. Consider the example project above:
+Using the example project above:
 
 <pre>
 # run all features
@@ -207,6 +250,8 @@ h4. Step Definitions
 
 Cellophane does assume that your steps are defined in files that follow the naming of your features. For each feature file that is found, Cellophane will look for a step file with the same name and automatically require it. To require shared step definitions, put them in a folder and include that folder in the @requires@ section of @.cellophane.yaml@.
 
+For example, if you have a feature defined in @<feature path>/admin/user/account_maintenance.feature@, Cellophane will automatically require a step definition file located in @<step path>/admin/user/account_maintenance_steps.rb@. Unless you are using nested step definitions in @.cellophane.yaml@ (@step_path: {nested_in: steps }@, in which case Cellophane will automatically require @<feature path>/admin/user/steps/account_maintenance_steps.rb@ if it exists.
+
 h4. Tags
 
 You don't need to use @. You can you want, but it's not necessary.

data/VERSION

@@ -1 +1 @@
-0.1.1
+0.1.2

data/cellophane.gemspec

@@ -5,11 +5,11 @@
 
 Gem::Specification.new do |s|
   s.name = %q{cellophane}
-  s.version = "0.1.1"
+  s.version = "0.1.2"
 
   s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
   s.authors = ["Phillip Koebbe"]
-  s.date = %q{2011-01-10}
+  s.date = %q{2011-01-11}
   s.default_executable = %q{cellophane}
   s.description = %q{Cellophane is a thin wrapper around Cucumber, making it easier to be creative when running features.}
   s.email = %q{phillip@livingdoor.net}
@@ -37,6 +37,7 @@ Gem::Specification.new do |s|
     "features/support/cellophane_steps.rb",
     "features/support/env.rb",
     "features/tags.feature",
+    "features/version.feature",
     "lib/cellophane/main.rb",
     "lib/cellophane/options.rb",
     "lib/cellophane/parser.rb"

data/features/support/cellophane_steps.rb

@@ -40,4 +40,8 @@ Given /^a project options file with the following options$/ do |lines|
 	
 	# already in the project dir
 	File.open(Cellophane::PROJECT_OPTIONS_FILE, 'w') { |f| f.write(contents) }
+end
+
+Given /^the current version should be displayed$/ do
+	@command.should =~ /#{Cellophane::VERSION}/
 end

data/features/version.feature

@@ -0,0 +1,13 @@
+Feature: Version
+
+@1
+Scenario: Short switch
+
+Given Cellophane is called with "-v"
+Then the current version should be displayed
+
+@2
+Scenario: Long switch
+
+Given Cellophane is called with "--version"
+Then the current version should be displayed

data/lib/cellophane/main.rb

@@ -4,6 +4,7 @@ require 'cellophane/options'
 
 module Cellophane
 	
+	VERSION = '0.1.2'
 	PROJECT_OPTIONS_FILE = '.cellophane.yaml'
 	
 	class Main
@@ -28,12 +29,14 @@ module Cellophane
 
 		def run
 			puts @message and return if @message
-			@options[:print] ? puts(@command) : system("#{@command}\n\n")
+			@options[:print] || @options[:version] ? puts(@command) : system("#{@command}\n\n")
 		end
 		
 		private
 		
 		def generate_command
+			return "cellophane #{Cellophane::VERSION}" if @options[:version]
+			
 			cuke_cmd = "#{@options[:cuke_command]} #{@options[:cucumber]}"
 
 			features = []

data/lib/cellophane/options.rb

@@ -34,6 +34,11 @@ module Cellophane
 					require 'ruby-debug'
 				end
 
+				# This displays the help screen, all programs are assumed to have this option.
+				opts.on( '-v', '--version', 'Display the version.' ) do
+					merged_options[:version] = true
+				end
+
 				# This displays the help screen, all programs are assumed to have this option.
 				opts.on( '-h', '--help', 'Display this screen.' ) do
 					puts opts

metadata

@@ -5,8 +5,8 @@ version: !ruby/object:Gem::Version
   segments: 
   - 0
   - 1
-  - 1
-  version: 0.1.1
+  - 2
+  version: 0.1.2
 platform: ruby
 authors: 
 - Phillip Koebbe
@@ -14,7 +14,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2011-01-10 00:00:00 -06:00
+date: 2011-01-11 00:00:00 -06:00
 default_executable: cellophane
 dependencies: []
 
@@ -46,6 +46,7 @@ files:
 - features/support/cellophane_steps.rb
 - features/support/env.rb
 - features/tags.feature
+- features/version.feature
 - lib/cellophane/main.rb
 - lib/cellophane/options.rb
 - lib/cellophane/parser.rb