cukable 0.1.2 → 0.1.3

data/.gitignore

@@ -1 +1,9 @@
+.rvmrc
 Gemfile.lock
+pkg/*
+.yardoc/*
+doc/*
+coverage/*
+coverage.data
+self_test/*
+

data/.yardopts

@@ -1,7 +1,8 @@
---readme README.md
+--readme docs/index.md
 --markup markdown
 --no-highlight
 lib/**/*.rb
 -
 History.md
+docs/*.md
 

data/History.md

@@ -1,6 +1,13 @@
 Cukable History
 ===============
 
+0.1.3
+-----
+
+- Documentation cleanup
+- Depend on `rubyslim-unofficial` instead of vendored gem
+
+
 0.1.2
 -----
 

data/README.md

@@ -2,420 +2,10 @@ Cukable
 =======
 
 Cukable allows you to write and execute [Cucumber](http://cukes.info) tests
-from [FitNesse](http://fitnesse.org).
+from [FitNesse](http://fitnesse.org). It consists of a
+[rubyslim](http://github.com/unclebob/rubyslim) fixture that invokes Cucumber,
+and a custom Cucumber output formatter that returns SliM-formatted test results
+to FitNesse. Cukable is licensed under the MIT License.
 
-It consists of a [rubyslim](http://github.com/unclebob/rubyslim) fixture that
-invokes Cucumber, and a custom Cucumber output formatter that returns
-SliM-formatted test results to FitNesse.
-
-
-Supported syntax
-----------------
-
-Most of the standard Cucumber/Gherkin syntax is supported by Cukable, including:
-
-- Background sections
-- Scenarios and Scenario Outlines with Examples
-- Multiple scenarios per feature
-- Multi-line table arguments and table diffing
-- Multi-line strings
-- Tags for running/skipping scenarios and defining drivers (such as `@selenium`)
-
-
-Installation
-------------
-
-To install Cukable, do:
-
-    $ gem install cukable
-
-Cukable requires [rubyslim](http://github.com/unclebob/rubyslim) in order to
-work; as of this writing, rubyslim is not officially packaged as a gem, making
-it slightly more difficult to get Cukable working. For this reason, a makeshift
-rubyslim gem is provided in the `vendor/cache` directory of Cukable. Use `gem
-list cukable -d` to find out the full installation path for cukable, then
-append `/vendor/cache/rubyslim-0.1.1.gem` on the end of that,a nd install like
-so:
-
-    $ gem install /path/to/cukable/vendor/cache/rubyslim-0.1.1.gem
-
-Please note that this is an unofficial gem, created without the sanction of the
-rubyslim author. Until such time as rubyslim gets an official gem distribution,
-please report any issues with it to the
-[Cukable issue tracker](http://github.com/wapcaplet/cukable/issues).
-
-
-Configuration
--------------
-
-FitNesse uses a JSON format for its test reporting, so you must enable the SLIM
-JSON output formatter provided by Cukable. To make Cucumber aware of this
-formatter, add this line:
-
-    require 'cukable/slim_json_formatter'
-
-to your `features/support/env.rb`, `features/support/custom_env.rb`, or
-wherever you're keeping custom initialization for your Cucumber environment.
-
-
-Converting existing features
-----------------------------
-
-Cukable comes with an executable script to convert existing Cucumber features
-to FitNesse wiki format. You must have an existing FitNesse page; features will
-be imported under that page.
-
-Usage:
-
-    cuke2fit <features_path> <fitnesse_path>
-
-For example, if your existing features are in `features/`, and the FitNesse
-wiki page you want to import them to is in `FitNesseRoot/MyTests`, do:
-
-    $ cuke2fit features FitNesseRoot/MyTests
-
-The hierarchy of your `features/` folder will be preserved as a hierarchy of
-FitNesse wiki pages. Each `.feature` file becomes a separate wiki page.
-
-
-Writing new features
---------------------
-
-You can write new Cucumber features from scratch, directly in FitNesse, and run
-them from FitNesse with only minimal configuration.
-
-Here's what a simple hierarchy might look like:
-
-- FitNesseRoot
-  - CukableTests (suite)
-    - SetUp
-    - FeedKitty (test)
-    - CleanLitterbox (test)
-
-Put these variable definitions in `CukableTests`:
-
-    !define TEST_SYSTEM {slim}
-    !define TEST_RUNNER {rubyslim}
-    !define COMMAND_PATTERN {rubyslim}
-
-This is the essential configuration to tell FitNesse how to invoke `rubyslim`
-for tests in the suite. Then put this in `CukableTests.SetUp`:
-
-    !| import |
-    | Cukable |
-
-This tells `rubyslim` to load the `Cukable` module, so it'll know how to run
-tests in `Cuke` tables. Now create a `Cuke` table in `CukableTests.FeedKitty`:
-
-    !| Table: Cuke                       |
-    | Feature: Feed kitty                |
-    |   Scenario: Canned food            |
-    |     Given I have a can of cat food |
-    |     When I feed it to my cat       |
-    |     Then the cat should purr       |
-
-The `!` that precedes the table ensures that all text within will be treated
-literally, and will not be marked up as FitNesse wiki-text. This is especially
-important if you have CamelCase words, email addresses, or URLs in your table.
-
-Also, note that all your steps must be defined in the usual way, such as `.rb`
-files in `features/step_definitions`. That's outside Cukable's scope.
-
-Finally, you can run the `FeedKitty` test by itself, or run the entire
-`CukableTests` suite.
-
-
-Test syntax
------------
-
-FitNesse uses wikitext tables delimited with a pipe `|` to format the
-executable statements of a test scenario; these are rendered as HTML tables in
-a FitNesse wiki page. When a test is run from FitNesse, the results of the test
-are rendered into the same table, with green- or red-highlighted cells indicating
-pass/fail status.
-
-Cucumber tests written in a FitNesse wiki page closely resemble the
-[Gherkin](http://github.com/aslakhellesoy/cucumber/wiki/gherkin) syntax that
-Cucumber understands, with some changes in formatting to accommodate FitNesse.
-
-If this is your `.feature` file:
-
-    Feature: Hello
-      Scenario: Hello world
-        Given I am on the hello page
-        Then I should see "Hello world"
-
-Then here is what your FitNesse wikitext would be:
-
-    !| Table: Cuke                        |
-    | Feature: Hello                      |
-    |   Scenario: Hello world             |
-    |     Given I am on the hello page    |
-    |     Then I should see "Hello world" |
-
-Each row of the FitNesse table contains one step or other directive. Whitespace
-before and/or after steps is not significant, so you can use it to aid
-readability if you're into that sort of thing.
-
-Your table must contain exactly one row with `Feature: ...`, and you must have
-at least one `Scenario: ...` or `Scenario Outline: ...`.
-
-
-Tables
-------
-
-Cucumber supports multiline step arguments in the form of tables; in a
-`.feature` file, these might look like:
-
-    Feature: Tables
-      Scenario: Fill in fields
-        Given I am on the contact page
-        When I fill in the following:
-          | Name | Email                 | Message |
-          | Eric | wapcaplet88@gmail.com | Howdy   |
-
-In a FitNesse wiki page, this would translate to:
-
-    !| Table: Cuke                                   |
-    | Feature: Tables                                |
-    |   Scenario: Fill in fields                     |
-    |     Given I am on the contact page             |
-    |     When I fill in the following:              |
-    |       | Name | Email                 | Message |
-    |       | Eric | wapcaplet88@gmail.com | Howdy   |
-
-That is, each row in an embedded table begins with an empty cell. The same
-applies to the "Examples" portion of a
-[Scenario Outline](https://github.com/aslakhellesoy/cucumber/wiki/scenario-outlines):
-
-    | When I look at paint samples |
-    | Then I should see "<color>"  |
-    | Examples:                    |
-    |   | color                    |
-    |   | Taupe                    |
-    |   | Vermilion                |
-    |   | Fuscia                   |
-
-
-Multi-line strings
-------------------
-
-To pass a multi-line string to one of your steps, just enter it as you normally
-would in a .feature file, with triple-double-quotes delimiting the string:
-
-    | When I fill in "Message" with: |
-    |   """                          |
-    |   So long, and                 |
-    |   thanks for all the fish!     |
-    |   """                          |
-
-
-Tags
-----
-
-You can include Cucumber tags, as long as you only include one tag per row in
-the table:
-
-    | @tag_a                      |
-    | @tag_b                      |
-    | Feature: Tagged feature     |
-    |   @tag_c                    |
-    |   @tag_d                    |
-    |   Scenario: Tagged scenario |
-    |     When I have some tags   |
-
-The inclusion of tags is useful for defining which driver to use (for example
-the `@selenium` tag supported by Capybara), as well as for controlling which
-tests are run via cucumber command-line arguments, described below.
-
-
-Acceleration
-------------
-
-Normally, FitNesse runs tests one-by-one. That is, under normal circumstances,
-each `Cuke` table will result in its own standalone execution of `cucumber`.
-This means that when you run a suite of tests, Cucumber will be running
-multiple times (once per feature) when it should really be running all features
-at once.
-
-This may be fine if your test environment is simple, and Cucumber runs quickly.
-But if your application has a lot of dependencies to load, there may be too much
-overhead to run a suite of tests in this way.
-
-Cukable provides a workaround to this in the form of something called `AaaAccelerator`.
-If you have a suite of three features:
-
-- MyFeatures (suite)
-    - FirstFeature (test)
-    - SecondFeature (test)
-    - ThirdFeature (test)
-
-and you want to be able to run the entire suite without invoking a separate
-Cucumber instance each time, simply create a new child page of `MyFeatures` called
-`AaaAccelerator` (named this way so it will be executed first in the suite):
-
-- MyFeatures (suite)
-    - AaaAccelerator (test)
-    - FirstFeature (test)
-    - SecondFeature (test)
-    - ThirdFeature (test)
-
-The `AaaAccelerator` page does not need to have any content; you can leave it
-empty if you like. Its existence alone will cause acceleration to take effect
-for the suite that it's in. To make this magic happen, you must add this to your
-`SetUp` page for the suite:
-
-    | script | Cuke |
-    | accelerate; | ${PAGE_PATH}.${PAGE_NAME} | ${CUCUMBER_ARGS} |
-
-Include this exactly as it appears; the variables will be expanded to the
-name of your `AaaAccelerator` page when the suite runs. The `CUCUMBER_ARGS`
-piece is an optional argument that passes any defined command-line arguments
-to Cucumber (see below).
-
-You can nest suites inside each other, and each suite can have its own
-`AaaAccelerator` page. Whenever you execute a suite, the highest-level
-accelerator will be executed (thus running as many features as possible
-together).
-
-
-Cucumber args
--------------
-
-There are two ways to pass command-line arguments to Cucumber when running
-features. The first is by passing an argument directly to the `Cuke`
-constructor in a feature table; just include an extra cell in the first row:
-
-    !| Table: Cuke | --tags @run_me    |
-    | Feature: Arguments               |
-    |   @run_me                        |
-    |   Scenario: This will be run     |
-    |   @dont_run_me                   |
-    |   Scenario: This will be skipped |
-
-This is the approach you'd use if you wanted to run a single test with
-specific command-line arguments. If you want to run an entire suite using
-the `AaaAccelerator` technique described above, you can define command-line
-arguments as a FitNesse variable, like this:
-
-    !define CUCUMBER_ARGS {--tags @run_me}
-
-Put this at the top of any suite page, and any `AaaAccelerator` in that suite
-will pass those additional arguments to Cucumber. Note that these will override
-any arguments passed to individual tables, because Cucumber is only executed
-once for the entire suite.
-
-
-Multiple projects
------------------
-
-As of Cukable version 0.1.2, you can run tests in multiple project directories.
-For example, you may have two applications that you want to test with Cukable:
-
-- `/home/eric/projects/A`: First application you want to test
-- `/home/eric/projects/B`: Second application you want to test
-- `/home/eric/projects/FitNesseRoot`: Where your wiki is stored
-
-Projects `A` and `B` may have different dependencies, and you want Cukable to
-mimic the process of running `cucumber` within each of those directories. If
-`A` and `B` are Rails applications, and you know what's good for you, you're
-already using [bundler](http://gembundler.com/) to manage each application's
-gem dependencies, and [RVM](http://rvm.beginrescueend.com/) with two distinct
-gemsets to keep the projects' dependencies from interfering with one another.
-This is what Cukable expects that you are doing.
-
-In your wiki pages (either in a `Cuke` table, or in the `accelerate` function
-call), you can pass a third argument (after `CUCUMBER_ARGS`) that indicates the
-directory where that test should be executed. For instance, you could have a
-wiki page with two tests--one for each project:
-
-    !| Table: Cuke | | /home/eric/projects/A |
-    | When I run a test on project A         |
-    | Then the test should pass              |
-
-    !| Table: Cuke | | /home/eric/projects/B   |
-    | When I run a different test on project B |
-    | Then the test should pass                |
-
-These two tests will be executed in their respective directories. If the two
-applications have differing gem dependencies, you should put an `.rvmrc` file
-in both the `A` and `B` directories, containing the correct `rvm` command to
-switch gemsets; if Cukable finds an `.rvmrc` in a project directory, it will be
-sourced so that Cucumber runs within the context of that gemset.
-
-
-Support
--------
-
-This README, along with API documentation on Cukable, are available on
-[rdoc.info](http://rdoc.info/github/wapcaplet/cukable/master/frames).
-
-Please report any bugs, complaints, and feature requests to the
-[issue tracker](http://github.com/wapcaplet/cukable/issues).
-
-
-Development
------------
-
-To hack on Cukable's code, first fork the
-[repository](http://github.com/wapcaplet/cukable),
-then clone your fork locally:
-
-    $ git clone git://github.com/your_username/cukable.git
-
-Install [bundler](http://gembundler.com/):
-
-    $ gem install bundler
-
-Then install Cukable's dependencies:
-
-    $ cd /path/to/cukable
-    $ bundle install
-
-It's a good idea to use [RVM](http://rvm.beginrescueend.com/)
-with a new gemset to keep things tidy.
-
-If you make changes that you'd like to share, push them into your fork,
-then [submit a pull request](http://github.com/wapcaplet/cukable/pulls).
-
-
-Testing
--------
-
-Cukable includes a suite of self-tests, executed using RSpec and Cucumber.
-These are in the `spec` and `features` directories, respectively. To run the
-full suite of tests, simply run:
-
-    $ rake
-
-This will generate output showing the status of each test, and will also use
-[rcov](http://eigenclass.org/hiki.rb?rcov) to write a code coverage report to
-`coverage/index.html`.
-
-
-Copyright
----------
-
-The MIT License
-
-Copyright (c) 2011 Automation Excellence
-
-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.
+[Full documentation is on rdoc.info](http://rdoc.info/github/wapcaplet/cukable/master/frames).
 

data/cukable.gemspec

@@ -1,6 +1,6 @@
 Gem::Specification.new do |s|
   s.name = "cukable"
-  s.version = "0.1.2"
+  s.version = "0.1.3"
   s.summary = "Runs Cucumber tests from FitNesse"
   s.description = <<-EOS
     Cukable allows running Cucumber test scenarios from FitNesse
@@ -13,6 +13,7 @@ Gem::Specification.new do |s|
   s.add_dependency 'json'
   s.add_dependency 'cucumber'
   s.add_dependency 'diff-lcs'
+  s.add_dependency 'rubyslim-unofficial'
 
   s.add_development_dependency 'rake', '~> 0.8.7'
   s.add_development_dependency 'rspec', '>= 2.2.0'

data/docs/accelerator.md

@@ -0,0 +1,51 @@
+Acceleration
+------------
+
+Normally, FitNesse runs tests one-by-one. That is, under normal circumstances,
+each `Cuke` table will result in its own standalone execution of `cucumber`.
+This means that when you run a suite of tests, Cucumber will be running
+multiple times (once per feature) when it should really be running all features
+at once.
+
+This may be fine if your test environment is simple, and Cucumber runs quickly.
+But if your application has a lot of dependencies to load, there may be too much
+overhead to run a suite of tests in this way.
+
+Cukable provides a workaround to this in the form of something called `AaaAccelerator`.
+If you have a suite of three features:
+
+- MyFeatures (suite)
+    - FirstFeature (test)
+    - SecondFeature (test)
+    - ThirdFeature (test)
+
+and you want to be able to run the entire suite without invoking a separate
+Cucumber instance each time, simply create a new child page of `MyFeatures` called
+`AaaAccelerator` (named this way so it will be executed first in the suite):
+
+- MyFeatures (suite)
+    - AaaAccelerator (test)
+    - FirstFeature (test)
+    - SecondFeature (test)
+    - ThirdFeature (test)
+
+The `AaaAccelerator` page does not need to have any content; you can leave it
+empty if you like. Its existence alone will cause acceleration to take effect
+for the suite that it's in. To make this magic happen, you must add this to your
+`SetUp` page for the suite:
+
+    | script | Cuke |
+    | accelerate; | ${PAGE_PATH}.${PAGE_NAME} | ${CUCUMBER_ARGS} |
+
+Include this exactly as it appears; the variables will be expanded to the
+name of your `AaaAccelerator` page when the suite runs. The `CUCUMBER_ARGS`
+piece is an optional argument that passes any defined command-line arguments
+to Cucumber (see below).
+
+You can nest suites inside each other, and each suite can have its own
+`AaaAccelerator` page. Whenever you execute a suite, the highest-level
+accelerator will be executed (thus running as many features as possible
+together).
+
+Next: [Cucumber Arguments](cucumber_args.md)
+

data/docs/converting.md

@@ -0,0 +1,21 @@
+Converting existing features
+----------------------------
+
+Cukable comes with an executable script to convert existing Cucumber features
+to FitNesse wiki format. You must have an existing FitNesse page; features will
+be imported under that page.
+
+Usage:
+
+    cuke2fit <features_path> <fitnesse_path>
+
+For example, if your existing features are in `features/`, and the FitNesse
+wiki page you want to import them to is in `FitNesseRoot/MyTests`, do:
+
+    $ cuke2fit features FitNesseRoot/MyTests
+
+The hierarchy of your `features/` folder will be preserved as a hierarchy of
+FitNesse wiki pages. Each `.feature` file becomes a separate wiki page.
+
+Next: [Writing New Features](writing_features.md)
+

data/docs/cucumber_args.md

@@ -0,0 +1,28 @@
+Cucumber arguments
+------------------
+
+There are two ways to pass command-line arguments to Cucumber when running
+features. The first is by passing an argument directly to the `Cuke`
+constructor in a feature table; just include an extra cell in the first row:
+
+    !| Table: Cuke | --tags @run_me    |
+    | Feature: Arguments               |
+    |   @run_me                        |
+    |   Scenario: This will be run     |
+    |   @dont_run_me                   |
+    |   Scenario: This will be skipped |
+
+This is the approach you'd use if you wanted to run a single test with
+specific command-line arguments. If you want to run an entire suite using
+the `AaaAccelerator` technique described above, you can define command-line
+arguments as a FitNesse variable, like this:
+
+    !define CUCUMBER_ARGS {--tags @run_me}
+
+Put this at the top of any suite page, and any `AaaAccelerator` in that suite
+will pass those additional arguments to Cucumber. Note that these will override
+any arguments passed to individual tables, because Cucumber is only executed
+once for the entire suite.
+
+Next: [Multiple Projects](multiple_projects.md)
+

data/docs/development.md

@@ -0,0 +1,39 @@
+Development
+-----------
+
+To hack on Cukable's code, first fork the
+[repository](http://github.com/wapcaplet/cukable),
+then clone your fork locally:
+
+    $ git clone git://github.com/your_username/cukable.git
+
+Install [bundler](http://gembundler.com/):
+
+    $ gem install bundler
+
+Then install Cukable's dependencies:
+
+    $ cd /path/to/cukable
+    $ bundle install
+
+It's a good idea to use [RVM](http://rvm.beginrescueend.com/)
+with a new gemset to keep things tidy.
+
+If you make changes that you'd like to share, push them into your fork,
+then [submit a pull request](http://github.com/wapcaplet/cukable/pulls).
+
+
+Testing
+-------
+
+Cukable includes a suite of self-tests, executed using RSpec and Cucumber.
+These are in the `spec` and `features` directories, respectively. To run the
+full suite of tests, simply run:
+
+    $ rake
+
+This will generate output showing the status of each test, and will also use
+[rcov](http://eigenclass.org/hiki.rb?rcov) to write a code coverage report to
+`coverage/index.html`.
+
+

data/docs/index.md

@@ -0,0 +1,22 @@
+Cukable
+-------
+
+Cukable allows you to write and execute [Cucumber](http://cukes.info) tests
+from [FitNesse](http://fitnesse.org). It consists of a
+[rubyslim](http://github.com/unclebob/rubyslim) fixture that invokes Cucumber,
+and a custom Cucumber output formatter that returns SliM-formatted test results
+to FitNesse.
+
+- [Installation & Configuration](install.md)
+- [Converting Existing Features](converting.md)
+- [Writing New Features](writing_features.md)
+- [Cukable Syntax](syntax.md)
+- [Acceleration](accelerator.md)
+- [Cucumber Arguments](cucumber_args.md)
+- [Multiple Projects](multiple_projects.md)
+- [Development & Testing](development.md)
+- [MIT License](license.md)
+
+Please report any bugs, complaints, and feature requests to the
+[issue tracker](http://github.com/wapcaplet/cukable/issues).
+

data/docs/install.md

@@ -0,0 +1,22 @@
+Installation
+------------
+
+To install Cukable, simply do:
+
+    $ gem install cukable
+
+
+Configuration
+-------------
+
+FitNesse uses a JSON format for its test reporting, so you must enable the SLIM
+JSON output formatter provided by Cukable. To make Cucumber aware of this
+formatter, add this line:
+
+    require 'cukable/slim_json_formatter'
+
+to your `features/support/env.rb`, `features/support/custom_env.rb`, or
+wherever you're keeping custom initialization for your Cucumber environment.
+
+
+Next: [Converting Existing Features](converting.md)

data/docs/license.md

@@ -0,0 +1,27 @@
+MIT License
+-----------
+
+Cukable is licensed under the MIT License.
+
+Copyright (c) 2011 Automation Excellence
+
+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/docs/multiple_projects.md

@@ -0,0 +1,39 @@
+Multiple projects
+-----------------
+
+As of Cukable version 0.1.2, you can run tests in multiple project directories.
+For example, you may have two applications that you want to test with Cukable:
+
+- `/home/eric/projects/A`: First application you want to test
+- `/home/eric/projects/B`: Second application you want to test
+- `/home/eric/projects/FitNesseRoot`: Where your wiki is stored
+
+Projects `A` and `B` may have different dependencies, and you want Cukable to
+mimic the process of running `cucumber` within each of those directories. If
+`A` and `B` are Rails applications, and you know what's good for you, you're
+already using [bundler](http://gembundler.com/) to manage each application's
+gem dependencies, and [RVM](http://rvm.beginrescueend.com/) with two distinct
+gemsets to keep the projects' dependencies from interfering with one another.
+This is what Cukable expects that you are doing.
+
+In your wiki pages (either in a `Cuke` table, or in the `accelerate` function
+call), you can pass a third argument (after `CUCUMBER_ARGS`) that indicates the
+directory where that test should be executed. For instance, you could have a
+wiki page with two tests--one for each project:
+
+    !| Table: Cuke | | /home/eric/projects/A |
+    | When I run a test on project A         |
+    | Then the test should pass              |
+
+    !| Table: Cuke | | /home/eric/projects/B   |
+    | When I run a different test on project B |
+    | Then the test should pass                |
+
+These two tests will be executed in their respective directories. If the two
+applications have differing gem dependencies, you should put an `.rvmrc` file
+in both the `A` and `B` directories, containing the correct `rvm` command to
+switch gemsets; if Cukable finds an `.rvmrc` in a project directory, it will be
+sourced so that Cucumber runs within the context of that gemset.
+
+Next: [Development & Testing](development.md)
+

data/docs/syntax.md

@@ -0,0 +1,117 @@
+Supported syntax
+----------------
+
+Most of the standard Cucumber/Gherkin syntax is supported by Cukable, including:
+
+- Background sections
+- Scenarios and Scenario Outlines with Examples
+- Multiple scenarios per feature
+- Multi-line table arguments and table diffing
+- Multi-line strings
+- Tags for running/skipping scenarios and defining drivers (such as `@selenium`)
+
+
+Test syntax
+-----------
+
+FitNesse uses wikitext tables delimited with a pipe `|` to format the
+executable statements of a test scenario; these are rendered as HTML tables in
+a FitNesse wiki page. When a test is run from FitNesse, the results of the test
+are rendered into the same table, with green- or red-highlighted cells indicating
+pass/fail status.
+
+Cucumber tests written in a FitNesse wiki page closely resemble the
+[Gherkin](http://github.com/aslakhellesoy/cucumber/wiki/gherkin) syntax that
+Cucumber understands, with some changes in formatting to accommodate FitNesse.
+
+If this is your `.feature` file:
+
+    Feature: Hello
+      Scenario: Hello world
+        Given I am on the hello page
+        Then I should see "Hello world"
+
+Then here is what your FitNesse wikitext would be:
+
+    !| Table: Cuke                        |
+    | Feature: Hello                      |
+    |   Scenario: Hello world             |
+    |     Given I am on the hello page    |
+    |     Then I should see "Hello world" |
+
+Each row of the FitNesse table contains one step or other directive. Whitespace
+before and/or after steps is not significant, so you can use it to aid
+readability if you're into that sort of thing.
+
+Your table must contain exactly one row with `Feature: ...`, and you must have
+at least one `Scenario: ...` or `Scenario Outline: ...`.
+
+
+Tables
+------
+
+Cucumber supports multiline step arguments in the form of tables; in a
+`.feature` file, these might look like:
+
+    Feature: Tables
+      Scenario: Fill in fields
+        Given I am on the contact page
+        When I fill in the following:
+          | Name | Email                 | Message |
+          | Eric | wapcaplet88@gmail.com | Howdy   |
+
+In a FitNesse wiki page, this would translate to:
+
+    !| Table: Cuke                                   |
+    | Feature: Tables                                |
+    |   Scenario: Fill in fields                     |
+    |     Given I am on the contact page             |
+    |     When I fill in the following:              |
+    |       | Name | Email                 | Message |
+    |       | Eric | wapcaplet88@gmail.com | Howdy   |
+
+That is, each row in an embedded table begins with an empty cell. The same
+applies to the "Examples" portion of a
+[Scenario Outline](https://github.com/aslakhellesoy/cucumber/wiki/scenario-outlines):
+
+    | When I look at paint samples |
+    | Then I should see "<color>"  |
+    | Examples:                    |
+    |   | color                    |
+    |   | Taupe                    |
+    |   | Vermilion                |
+    |   | Fuscia                   |
+
+
+Multi-line strings
+------------------
+
+To pass a multi-line string to one of your steps, just enter it as you normally
+would in a .feature file, with triple-double-quotes delimiting the string:
+
+    | When I fill in "Message" with: |
+    |   """                          |
+    |   So long, and                 |
+    |   thanks for all the fish!     |
+    |   """                          |
+
+
+Tags
+----
+
+You can include Cucumber tags, as long as you only include one tag per row in
+the table:
+
+    | @tag_a                      |
+    | @tag_b                      |
+    | Feature: Tagged feature     |
+    |   @tag_c                    |
+    |   @tag_d                    |
+    |   Scenario: Tagged scenario |
+    |     When I have some tags   |
+
+The inclusion of tags is useful for defining which driver to use (for example
+the `@selenium` tag supported by Capybara), as well as for controlling which
+tests are run via cucumber command-line arguments, described below.
+
+Next: [Acceleration](accelerator.md)

data/docs/writing_features.md

@@ -0,0 +1,48 @@
+Writing new features
+--------------------
+
+You can write new Cucumber features from scratch, directly in FitNesse, and run
+them from FitNesse with only minimal configuration.
+
+Here's what a simple hierarchy might look like:
+
+- FitNesseRoot
+  - CukableTests (suite)
+    - SetUp
+    - FeedKitty (test)
+    - CleanLitterbox (test)
+
+Put these variable definitions in `CukableTests`:
+
+    !define TEST_SYSTEM {slim}
+    !define TEST_RUNNER {rubyslim}
+    !define COMMAND_PATTERN {rubyslim}
+
+This is the essential configuration to tell FitNesse how to invoke `rubyslim`
+for tests in the suite. Then put this in `CukableTests.SetUp`:
+
+    !| import |
+    | Cukable |
+
+This tells `rubyslim` to load the `Cukable` module, so it'll know how to run
+tests in `Cuke` tables. Now create a `Cuke` table in `CukableTests.FeedKitty`:
+
+    !| Table: Cuke                       |
+    | Feature: Feed kitty                |
+    |   Scenario: Canned food            |
+    |     Given I have a can of cat food |
+    |     When I feed it to my cat       |
+    |     Then the cat should purr       |
+
+The `!` that precedes the table ensures that all text within will be treated
+literally, and will not be marked up as FitNesse wiki-text. This is especially
+important if you have CamelCase words, email addresses, or URLs in your table.
+
+Also, note that all your steps must be defined in the usual way, such as `.rb`
+files in `features/step_definitions`. That's outside Cukable's scope.
+
+Finally, you can run the `FeedKitty` test by itself, or run the entire
+`CukableTests` suite.
+
+Next: [Cukable Syntax](syntax.md)
+

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification 
 name: cukable
 version: !ruby/object:Gem::Version 
-  hash: 31
+  hash: 29
   prerelease: false
   segments: 
   - 0
   - 1
-  - 2
-  version: 0.1.2
+  - 3
+  version: 0.1.3
 platform: ruby
 authors: 
 - Eric Pierce
@@ -16,7 +16,7 @@ autorequire:
 bindir: bin
 cert_chain: []
 
-date: 2011-07-09 00:00:00 -06:00
+date: 2011-07-22 00:00:00 -06:00
 default_executable: 
 dependencies: 
 - !ruby/object:Gem::Dependency 
@@ -62,9 +62,23 @@ dependencies:
   type: :runtime
   version_requirements: *id003
 - !ruby/object:Gem::Dependency 
-  name: rake
+  name: rubyslim-unofficial
   prerelease: false
   requirement: &id004 !ruby/object:Gem::Requirement 
+    none: false
+    requirements: 
+    - - ">="
+      - !ruby/object:Gem::Version 
+        hash: 3
+        segments: 
+        - 0
+        version: "0"
+  type: :runtime
+  version_requirements: *id004
+- !ruby/object:Gem::Dependency 
+  name: rake
+  prerelease: false
+  requirement: &id005 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ~>
@@ -76,11 +90,11 @@ dependencies:
         - 7
         version: 0.8.7
   type: :development
-  version_requirements: *id004
+  version_requirements: *id005
 - !ruby/object:Gem::Dependency 
   name: rspec
   prerelease: false
-  requirement: &id005 !ruby/object:Gem::Requirement 
+  requirement: &id006 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ">="
@@ -92,11 +106,11 @@ dependencies:
         - 0
         version: 2.2.0
   type: :development
-  version_requirements: *id005
+  version_requirements: *id006
 - !ruby/object:Gem::Dependency 
   name: rcov
   prerelease: false
-  requirement: &id006 !ruby/object:Gem::Requirement 
+  requirement: &id007 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ">="
@@ -106,11 +120,11 @@ dependencies:
         - 0
         version: "0"
   type: :development
-  version_requirements: *id006
+  version_requirements: *id007
 - !ruby/object:Gem::Dependency 
   name: yard
   prerelease: false
-  requirement: &id007 !ruby/object:Gem::Requirement 
+  requirement: &id008 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ">="
@@ -120,11 +134,11 @@ dependencies:
         - 0
         version: "0"
   type: :development
-  version_requirements: *id007
+  version_requirements: *id008
 - !ruby/object:Gem::Dependency 
   name: bluecloth
   prerelease: false
-  requirement: &id008 !ruby/object:Gem::Requirement 
+  requirement: &id009 !ruby/object:Gem::Requirement 
     none: false
     requirements: 
     - - ">="
@@ -134,7 +148,7 @@ dependencies:
         - 0
         version: "0"
   type: :development
-  version_requirements: *id008
+  version_requirements: *id009
 description: "    Cukable allows running Cucumber test scenarios from FitNesse\n"
 email: wapcaplet88@gmail.com
 executables: 
@@ -152,6 +166,16 @@ files:
 - Rakefile
 - bin/cuke2fit
 - cukable.gemspec
+- docs/accelerator.md
+- docs/converting.md
+- docs/cucumber_args.md
+- docs/development.md
+- docs/index.md
+- docs/install.md
+- docs/license.md
+- docs/multiple_projects.md
+- docs/syntax.md
+- docs/writing_features.md
 - features/conversion.feature
 - features/cuke_fixture.feature
 - features/slim_json_formatter.feature
@@ -166,7 +190,6 @@ files:
 - spec/cuke_spec.rb
 - spec/helper_spec.rb
 - spec/spec_helper.rb
-- vendor/cache/rubyslim-0.1.1.gem
 has_rdoc: true
 homepage: http://github.com/wapcaplet/cukable
 licenses: []