cukable 0.1.2 → 0.1.3
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +8 -0
- data/.yardopts +2 -1
- data/History.md +7 -0
- data/README.md +5 -415
- data/cukable.gemspec +2 -1
- data/docs/accelerator.md +51 -0
- data/docs/converting.md +21 -0
- data/docs/cucumber_args.md +28 -0
- data/docs/development.md +39 -0
- data/docs/index.md +22 -0
- data/docs/install.md +22 -0
- data/docs/license.md +27 -0
- data/docs/multiple_projects.md +39 -0
- data/docs/syntax.md +117 -0
- data/docs/writing_features.md +48 -0
- metadata +38 -15
- data/vendor/cache/rubyslim-0.1.1.gem +0 -0
data/.gitignore
CHANGED
data/.yardopts
CHANGED
data/History.md
CHANGED
data/README.md
CHANGED
@@ -2,420 +2,10 @@ Cukable
|
|
2
2
|
=======
|
3
3
|
|
4
4
|
Cukable allows you to write and execute [Cucumber](http://cukes.info) tests
|
5
|
-
from [FitNesse](http://fitnesse.org).
|
5
|
+
from [FitNesse](http://fitnesse.org). It consists of a
|
6
|
+
[rubyslim](http://github.com/unclebob/rubyslim) fixture that invokes Cucumber,
|
7
|
+
and a custom Cucumber output formatter that returns SliM-formatted test results
|
8
|
+
to FitNesse. Cukable is licensed under the MIT License.
|
6
9
|
|
7
|
-
|
8
|
-
invokes Cucumber, and a custom Cucumber output formatter that returns
|
9
|
-
SliM-formatted test results to FitNesse.
|
10
|
-
|
11
|
-
|
12
|
-
Supported syntax
|
13
|
-
----------------
|
14
|
-
|
15
|
-
Most of the standard Cucumber/Gherkin syntax is supported by Cukable, including:
|
16
|
-
|
17
|
-
- Background sections
|
18
|
-
- Scenarios and Scenario Outlines with Examples
|
19
|
-
- Multiple scenarios per feature
|
20
|
-
- Multi-line table arguments and table diffing
|
21
|
-
- Multi-line strings
|
22
|
-
- Tags for running/skipping scenarios and defining drivers (such as `@selenium`)
|
23
|
-
|
24
|
-
|
25
|
-
Installation
|
26
|
-
------------
|
27
|
-
|
28
|
-
To install Cukable, do:
|
29
|
-
|
30
|
-
$ gem install cukable
|
31
|
-
|
32
|
-
Cukable requires [rubyslim](http://github.com/unclebob/rubyslim) in order to
|
33
|
-
work; as of this writing, rubyslim is not officially packaged as a gem, making
|
34
|
-
it slightly more difficult to get Cukable working. For this reason, a makeshift
|
35
|
-
rubyslim gem is provided in the `vendor/cache` directory of Cukable. Use `gem
|
36
|
-
list cukable -d` to find out the full installation path for cukable, then
|
37
|
-
append `/vendor/cache/rubyslim-0.1.1.gem` on the end of that,a nd install like
|
38
|
-
so:
|
39
|
-
|
40
|
-
$ gem install /path/to/cukable/vendor/cache/rubyslim-0.1.1.gem
|
41
|
-
|
42
|
-
Please note that this is an unofficial gem, created without the sanction of the
|
43
|
-
rubyslim author. Until such time as rubyslim gets an official gem distribution,
|
44
|
-
please report any issues with it to the
|
45
|
-
[Cukable issue tracker](http://github.com/wapcaplet/cukable/issues).
|
46
|
-
|
47
|
-
|
48
|
-
Configuration
|
49
|
-
-------------
|
50
|
-
|
51
|
-
FitNesse uses a JSON format for its test reporting, so you must enable the SLIM
|
52
|
-
JSON output formatter provided by Cukable. To make Cucumber aware of this
|
53
|
-
formatter, add this line:
|
54
|
-
|
55
|
-
require 'cukable/slim_json_formatter'
|
56
|
-
|
57
|
-
to your `features/support/env.rb`, `features/support/custom_env.rb`, or
|
58
|
-
wherever you're keeping custom initialization for your Cucumber environment.
|
59
|
-
|
60
|
-
|
61
|
-
Converting existing features
|
62
|
-
----------------------------
|
63
|
-
|
64
|
-
Cukable comes with an executable script to convert existing Cucumber features
|
65
|
-
to FitNesse wiki format. You must have an existing FitNesse page; features will
|
66
|
-
be imported under that page.
|
67
|
-
|
68
|
-
Usage:
|
69
|
-
|
70
|
-
cuke2fit <features_path> <fitnesse_path>
|
71
|
-
|
72
|
-
For example, if your existing features are in `features/`, and the FitNesse
|
73
|
-
wiki page you want to import them to is in `FitNesseRoot/MyTests`, do:
|
74
|
-
|
75
|
-
$ cuke2fit features FitNesseRoot/MyTests
|
76
|
-
|
77
|
-
The hierarchy of your `features/` folder will be preserved as a hierarchy of
|
78
|
-
FitNesse wiki pages. Each `.feature` file becomes a separate wiki page.
|
79
|
-
|
80
|
-
|
81
|
-
Writing new features
|
82
|
-
--------------------
|
83
|
-
|
84
|
-
You can write new Cucumber features from scratch, directly in FitNesse, and run
|
85
|
-
them from FitNesse with only minimal configuration.
|
86
|
-
|
87
|
-
Here's what a simple hierarchy might look like:
|
88
|
-
|
89
|
-
- FitNesseRoot
|
90
|
-
- CukableTests (suite)
|
91
|
-
- SetUp
|
92
|
-
- FeedKitty (test)
|
93
|
-
- CleanLitterbox (test)
|
94
|
-
|
95
|
-
Put these variable definitions in `CukableTests`:
|
96
|
-
|
97
|
-
!define TEST_SYSTEM {slim}
|
98
|
-
!define TEST_RUNNER {rubyslim}
|
99
|
-
!define COMMAND_PATTERN {rubyslim}
|
100
|
-
|
101
|
-
This is the essential configuration to tell FitNesse how to invoke `rubyslim`
|
102
|
-
for tests in the suite. Then put this in `CukableTests.SetUp`:
|
103
|
-
|
104
|
-
!| import |
|
105
|
-
| Cukable |
|
106
|
-
|
107
|
-
This tells `rubyslim` to load the `Cukable` module, so it'll know how to run
|
108
|
-
tests in `Cuke` tables. Now create a `Cuke` table in `CukableTests.FeedKitty`:
|
109
|
-
|
110
|
-
!| Table: Cuke |
|
111
|
-
| Feature: Feed kitty |
|
112
|
-
| Scenario: Canned food |
|
113
|
-
| Given I have a can of cat food |
|
114
|
-
| When I feed it to my cat |
|
115
|
-
| Then the cat should purr |
|
116
|
-
|
117
|
-
The `!` that precedes the table ensures that all text within will be treated
|
118
|
-
literally, and will not be marked up as FitNesse wiki-text. This is especially
|
119
|
-
important if you have CamelCase words, email addresses, or URLs in your table.
|
120
|
-
|
121
|
-
Also, note that all your steps must be defined in the usual way, such as `.rb`
|
122
|
-
files in `features/step_definitions`. That's outside Cukable's scope.
|
123
|
-
|
124
|
-
Finally, you can run the `FeedKitty` test by itself, or run the entire
|
125
|
-
`CukableTests` suite.
|
126
|
-
|
127
|
-
|
128
|
-
Test syntax
|
129
|
-
-----------
|
130
|
-
|
131
|
-
FitNesse uses wikitext tables delimited with a pipe `|` to format the
|
132
|
-
executable statements of a test scenario; these are rendered as HTML tables in
|
133
|
-
a FitNesse wiki page. When a test is run from FitNesse, the results of the test
|
134
|
-
are rendered into the same table, with green- or red-highlighted cells indicating
|
135
|
-
pass/fail status.
|
136
|
-
|
137
|
-
Cucumber tests written in a FitNesse wiki page closely resemble the
|
138
|
-
[Gherkin](http://github.com/aslakhellesoy/cucumber/wiki/gherkin) syntax that
|
139
|
-
Cucumber understands, with some changes in formatting to accommodate FitNesse.
|
140
|
-
|
141
|
-
If this is your `.feature` file:
|
142
|
-
|
143
|
-
Feature: Hello
|
144
|
-
Scenario: Hello world
|
145
|
-
Given I am on the hello page
|
146
|
-
Then I should see "Hello world"
|
147
|
-
|
148
|
-
Then here is what your FitNesse wikitext would be:
|
149
|
-
|
150
|
-
!| Table: Cuke |
|
151
|
-
| Feature: Hello |
|
152
|
-
| Scenario: Hello world |
|
153
|
-
| Given I am on the hello page |
|
154
|
-
| Then I should see "Hello world" |
|
155
|
-
|
156
|
-
Each row of the FitNesse table contains one step or other directive. Whitespace
|
157
|
-
before and/or after steps is not significant, so you can use it to aid
|
158
|
-
readability if you're into that sort of thing.
|
159
|
-
|
160
|
-
Your table must contain exactly one row with `Feature: ...`, and you must have
|
161
|
-
at least one `Scenario: ...` or `Scenario Outline: ...`.
|
162
|
-
|
163
|
-
|
164
|
-
Tables
|
165
|
-
------
|
166
|
-
|
167
|
-
Cucumber supports multiline step arguments in the form of tables; in a
|
168
|
-
`.feature` file, these might look like:
|
169
|
-
|
170
|
-
Feature: Tables
|
171
|
-
Scenario: Fill in fields
|
172
|
-
Given I am on the contact page
|
173
|
-
When I fill in the following:
|
174
|
-
| Name | Email | Message |
|
175
|
-
| Eric | wapcaplet88@gmail.com | Howdy |
|
176
|
-
|
177
|
-
In a FitNesse wiki page, this would translate to:
|
178
|
-
|
179
|
-
!| Table: Cuke |
|
180
|
-
| Feature: Tables |
|
181
|
-
| Scenario: Fill in fields |
|
182
|
-
| Given I am on the contact page |
|
183
|
-
| When I fill in the following: |
|
184
|
-
| | Name | Email | Message |
|
185
|
-
| | Eric | wapcaplet88@gmail.com | Howdy |
|
186
|
-
|
187
|
-
That is, each row in an embedded table begins with an empty cell. The same
|
188
|
-
applies to the "Examples" portion of a
|
189
|
-
[Scenario Outline](https://github.com/aslakhellesoy/cucumber/wiki/scenario-outlines):
|
190
|
-
|
191
|
-
| When I look at paint samples |
|
192
|
-
| Then I should see "<color>" |
|
193
|
-
| Examples: |
|
194
|
-
| | color |
|
195
|
-
| | Taupe |
|
196
|
-
| | Vermilion |
|
197
|
-
| | Fuscia |
|
198
|
-
|
199
|
-
|
200
|
-
Multi-line strings
|
201
|
-
------------------
|
202
|
-
|
203
|
-
To pass a multi-line string to one of your steps, just enter it as you normally
|
204
|
-
would in a .feature file, with triple-double-quotes delimiting the string:
|
205
|
-
|
206
|
-
| When I fill in "Message" with: |
|
207
|
-
| """ |
|
208
|
-
| So long, and |
|
209
|
-
| thanks for all the fish! |
|
210
|
-
| """ |
|
211
|
-
|
212
|
-
|
213
|
-
Tags
|
214
|
-
----
|
215
|
-
|
216
|
-
You can include Cucumber tags, as long as you only include one tag per row in
|
217
|
-
the table:
|
218
|
-
|
219
|
-
| @tag_a |
|
220
|
-
| @tag_b |
|
221
|
-
| Feature: Tagged feature |
|
222
|
-
| @tag_c |
|
223
|
-
| @tag_d |
|
224
|
-
| Scenario: Tagged scenario |
|
225
|
-
| When I have some tags |
|
226
|
-
|
227
|
-
The inclusion of tags is useful for defining which driver to use (for example
|
228
|
-
the `@selenium` tag supported by Capybara), as well as for controlling which
|
229
|
-
tests are run via cucumber command-line arguments, described below.
|
230
|
-
|
231
|
-
|
232
|
-
Acceleration
|
233
|
-
------------
|
234
|
-
|
235
|
-
Normally, FitNesse runs tests one-by-one. That is, under normal circumstances,
|
236
|
-
each `Cuke` table will result in its own standalone execution of `cucumber`.
|
237
|
-
This means that when you run a suite of tests, Cucumber will be running
|
238
|
-
multiple times (once per feature) when it should really be running all features
|
239
|
-
at once.
|
240
|
-
|
241
|
-
This may be fine if your test environment is simple, and Cucumber runs quickly.
|
242
|
-
But if your application has a lot of dependencies to load, there may be too much
|
243
|
-
overhead to run a suite of tests in this way.
|
244
|
-
|
245
|
-
Cukable provides a workaround to this in the form of something called `AaaAccelerator`.
|
246
|
-
If you have a suite of three features:
|
247
|
-
|
248
|
-
- MyFeatures (suite)
|
249
|
-
- FirstFeature (test)
|
250
|
-
- SecondFeature (test)
|
251
|
-
- ThirdFeature (test)
|
252
|
-
|
253
|
-
and you want to be able to run the entire suite without invoking a separate
|
254
|
-
Cucumber instance each time, simply create a new child page of `MyFeatures` called
|
255
|
-
`AaaAccelerator` (named this way so it will be executed first in the suite):
|
256
|
-
|
257
|
-
- MyFeatures (suite)
|
258
|
-
- AaaAccelerator (test)
|
259
|
-
- FirstFeature (test)
|
260
|
-
- SecondFeature (test)
|
261
|
-
- ThirdFeature (test)
|
262
|
-
|
263
|
-
The `AaaAccelerator` page does not need to have any content; you can leave it
|
264
|
-
empty if you like. Its existence alone will cause acceleration to take effect
|
265
|
-
for the suite that it's in. To make this magic happen, you must add this to your
|
266
|
-
`SetUp` page for the suite:
|
267
|
-
|
268
|
-
| script | Cuke |
|
269
|
-
| accelerate; | ${PAGE_PATH}.${PAGE_NAME} | ${CUCUMBER_ARGS} |
|
270
|
-
|
271
|
-
Include this exactly as it appears; the variables will be expanded to the
|
272
|
-
name of your `AaaAccelerator` page when the suite runs. The `CUCUMBER_ARGS`
|
273
|
-
piece is an optional argument that passes any defined command-line arguments
|
274
|
-
to Cucumber (see below).
|
275
|
-
|
276
|
-
You can nest suites inside each other, and each suite can have its own
|
277
|
-
`AaaAccelerator` page. Whenever you execute a suite, the highest-level
|
278
|
-
accelerator will be executed (thus running as many features as possible
|
279
|
-
together).
|
280
|
-
|
281
|
-
|
282
|
-
Cucumber args
|
283
|
-
-------------
|
284
|
-
|
285
|
-
There are two ways to pass command-line arguments to Cucumber when running
|
286
|
-
features. The first is by passing an argument directly to the `Cuke`
|
287
|
-
constructor in a feature table; just include an extra cell in the first row:
|
288
|
-
|
289
|
-
!| Table: Cuke | --tags @run_me |
|
290
|
-
| Feature: Arguments |
|
291
|
-
| @run_me |
|
292
|
-
| Scenario: This will be run |
|
293
|
-
| @dont_run_me |
|
294
|
-
| Scenario: This will be skipped |
|
295
|
-
|
296
|
-
This is the approach you'd use if you wanted to run a single test with
|
297
|
-
specific command-line arguments. If you want to run an entire suite using
|
298
|
-
the `AaaAccelerator` technique described above, you can define command-line
|
299
|
-
arguments as a FitNesse variable, like this:
|
300
|
-
|
301
|
-
!define CUCUMBER_ARGS {--tags @run_me}
|
302
|
-
|
303
|
-
Put this at the top of any suite page, and any `AaaAccelerator` in that suite
|
304
|
-
will pass those additional arguments to Cucumber. Note that these will override
|
305
|
-
any arguments passed to individual tables, because Cucumber is only executed
|
306
|
-
once for the entire suite.
|
307
|
-
|
308
|
-
|
309
|
-
Multiple projects
|
310
|
-
-----------------
|
311
|
-
|
312
|
-
As of Cukable version 0.1.2, you can run tests in multiple project directories.
|
313
|
-
For example, you may have two applications that you want to test with Cukable:
|
314
|
-
|
315
|
-
- `/home/eric/projects/A`: First application you want to test
|
316
|
-
- `/home/eric/projects/B`: Second application you want to test
|
317
|
-
- `/home/eric/projects/FitNesseRoot`: Where your wiki is stored
|
318
|
-
|
319
|
-
Projects `A` and `B` may have different dependencies, and you want Cukable to
|
320
|
-
mimic the process of running `cucumber` within each of those directories. If
|
321
|
-
`A` and `B` are Rails applications, and you know what's good for you, you're
|
322
|
-
already using [bundler](http://gembundler.com/) to manage each application's
|
323
|
-
gem dependencies, and [RVM](http://rvm.beginrescueend.com/) with two distinct
|
324
|
-
gemsets to keep the projects' dependencies from interfering with one another.
|
325
|
-
This is what Cukable expects that you are doing.
|
326
|
-
|
327
|
-
In your wiki pages (either in a `Cuke` table, or in the `accelerate` function
|
328
|
-
call), you can pass a third argument (after `CUCUMBER_ARGS`) that indicates the
|
329
|
-
directory where that test should be executed. For instance, you could have a
|
330
|
-
wiki page with two tests--one for each project:
|
331
|
-
|
332
|
-
!| Table: Cuke | | /home/eric/projects/A |
|
333
|
-
| When I run a test on project A |
|
334
|
-
| Then the test should pass |
|
335
|
-
|
336
|
-
!| Table: Cuke | | /home/eric/projects/B |
|
337
|
-
| When I run a different test on project B |
|
338
|
-
| Then the test should pass |
|
339
|
-
|
340
|
-
These two tests will be executed in their respective directories. If the two
|
341
|
-
applications have differing gem dependencies, you should put an `.rvmrc` file
|
342
|
-
in both the `A` and `B` directories, containing the correct `rvm` command to
|
343
|
-
switch gemsets; if Cukable finds an `.rvmrc` in a project directory, it will be
|
344
|
-
sourced so that Cucumber runs within the context of that gemset.
|
345
|
-
|
346
|
-
|
347
|
-
Support
|
348
|
-
-------
|
349
|
-
|
350
|
-
This README, along with API documentation on Cukable, are available on
|
351
|
-
[rdoc.info](http://rdoc.info/github/wapcaplet/cukable/master/frames).
|
352
|
-
|
353
|
-
Please report any bugs, complaints, and feature requests to the
|
354
|
-
[issue tracker](http://github.com/wapcaplet/cukable/issues).
|
355
|
-
|
356
|
-
|
357
|
-
Development
|
358
|
-
-----------
|
359
|
-
|
360
|
-
To hack on Cukable's code, first fork the
|
361
|
-
[repository](http://github.com/wapcaplet/cukable),
|
362
|
-
then clone your fork locally:
|
363
|
-
|
364
|
-
$ git clone git://github.com/your_username/cukable.git
|
365
|
-
|
366
|
-
Install [bundler](http://gembundler.com/):
|
367
|
-
|
368
|
-
$ gem install bundler
|
369
|
-
|
370
|
-
Then install Cukable's dependencies:
|
371
|
-
|
372
|
-
$ cd /path/to/cukable
|
373
|
-
$ bundle install
|
374
|
-
|
375
|
-
It's a good idea to use [RVM](http://rvm.beginrescueend.com/)
|
376
|
-
with a new gemset to keep things tidy.
|
377
|
-
|
378
|
-
If you make changes that you'd like to share, push them into your fork,
|
379
|
-
then [submit a pull request](http://github.com/wapcaplet/cukable/pulls).
|
380
|
-
|
381
|
-
|
382
|
-
Testing
|
383
|
-
-------
|
384
|
-
|
385
|
-
Cukable includes a suite of self-tests, executed using RSpec and Cucumber.
|
386
|
-
These are in the `spec` and `features` directories, respectively. To run the
|
387
|
-
full suite of tests, simply run:
|
388
|
-
|
389
|
-
$ rake
|
390
|
-
|
391
|
-
This will generate output showing the status of each test, and will also use
|
392
|
-
[rcov](http://eigenclass.org/hiki.rb?rcov) to write a code coverage report to
|
393
|
-
`coverage/index.html`.
|
394
|
-
|
395
|
-
|
396
|
-
Copyright
|
397
|
-
---------
|
398
|
-
|
399
|
-
The MIT License
|
400
|
-
|
401
|
-
Copyright (c) 2011 Automation Excellence
|
402
|
-
|
403
|
-
Permission is hereby granted, free of charge, to any person obtaining
|
404
|
-
a copy of this software and associated documentation files (the
|
405
|
-
"Software"), to deal in the Software without restriction, including
|
406
|
-
without limitation the rights to use, copy, modify, merge, publish,
|
407
|
-
distribute, sublicense, and/or sell copies of the Software, and to
|
408
|
-
permit persons to whom the Software is furnished to do so, subject to
|
409
|
-
the following conditions:
|
410
|
-
|
411
|
-
The above copyright notice and this permission notice shall be
|
412
|
-
included in all copies or substantial portions of the Software.
|
413
|
-
|
414
|
-
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
415
|
-
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
416
|
-
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
417
|
-
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
418
|
-
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
419
|
-
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
420
|
-
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
10
|
+
[Full documentation is on rdoc.info](http://rdoc.info/github/wapcaplet/cukable/master/frames).
|
421
11
|
|
data/cukable.gemspec
CHANGED
@@ -1,6 +1,6 @@
|
|
1
1
|
Gem::Specification.new do |s|
|
2
2
|
s.name = "cukable"
|
3
|
-
s.version = "0.1.
|
3
|
+
s.version = "0.1.3"
|
4
4
|
s.summary = "Runs Cucumber tests from FitNesse"
|
5
5
|
s.description = <<-EOS
|
6
6
|
Cukable allows running Cucumber test scenarios from FitNesse
|
@@ -13,6 +13,7 @@ Gem::Specification.new do |s|
|
|
13
13
|
s.add_dependency 'json'
|
14
14
|
s.add_dependency 'cucumber'
|
15
15
|
s.add_dependency 'diff-lcs'
|
16
|
+
s.add_dependency 'rubyslim-unofficial'
|
16
17
|
|
17
18
|
s.add_development_dependency 'rake', '~> 0.8.7'
|
18
19
|
s.add_development_dependency 'rspec', '>= 2.2.0'
|
data/docs/accelerator.md
ADDED
@@ -0,0 +1,51 @@
|
|
1
|
+
Acceleration
|
2
|
+
------------
|
3
|
+
|
4
|
+
Normally, FitNesse runs tests one-by-one. That is, under normal circumstances,
|
5
|
+
each `Cuke` table will result in its own standalone execution of `cucumber`.
|
6
|
+
This means that when you run a suite of tests, Cucumber will be running
|
7
|
+
multiple times (once per feature) when it should really be running all features
|
8
|
+
at once.
|
9
|
+
|
10
|
+
This may be fine if your test environment is simple, and Cucumber runs quickly.
|
11
|
+
But if your application has a lot of dependencies to load, there may be too much
|
12
|
+
overhead to run a suite of tests in this way.
|
13
|
+
|
14
|
+
Cukable provides a workaround to this in the form of something called `AaaAccelerator`.
|
15
|
+
If you have a suite of three features:
|
16
|
+
|
17
|
+
- MyFeatures (suite)
|
18
|
+
- FirstFeature (test)
|
19
|
+
- SecondFeature (test)
|
20
|
+
- ThirdFeature (test)
|
21
|
+
|
22
|
+
and you want to be able to run the entire suite without invoking a separate
|
23
|
+
Cucumber instance each time, simply create a new child page of `MyFeatures` called
|
24
|
+
`AaaAccelerator` (named this way so it will be executed first in the suite):
|
25
|
+
|
26
|
+
- MyFeatures (suite)
|
27
|
+
- AaaAccelerator (test)
|
28
|
+
- FirstFeature (test)
|
29
|
+
- SecondFeature (test)
|
30
|
+
- ThirdFeature (test)
|
31
|
+
|
32
|
+
The `AaaAccelerator` page does not need to have any content; you can leave it
|
33
|
+
empty if you like. Its existence alone will cause acceleration to take effect
|
34
|
+
for the suite that it's in. To make this magic happen, you must add this to your
|
35
|
+
`SetUp` page for the suite:
|
36
|
+
|
37
|
+
| script | Cuke |
|
38
|
+
| accelerate; | ${PAGE_PATH}.${PAGE_NAME} | ${CUCUMBER_ARGS} |
|
39
|
+
|
40
|
+
Include this exactly as it appears; the variables will be expanded to the
|
41
|
+
name of your `AaaAccelerator` page when the suite runs. The `CUCUMBER_ARGS`
|
42
|
+
piece is an optional argument that passes any defined command-line arguments
|
43
|
+
to Cucumber (see below).
|
44
|
+
|
45
|
+
You can nest suites inside each other, and each suite can have its own
|
46
|
+
`AaaAccelerator` page. Whenever you execute a suite, the highest-level
|
47
|
+
accelerator will be executed (thus running as many features as possible
|
48
|
+
together).
|
49
|
+
|
50
|
+
Next: [Cucumber Arguments](cucumber_args.md)
|
51
|
+
|
data/docs/converting.md
ADDED
@@ -0,0 +1,21 @@
|
|
1
|
+
Converting existing features
|
2
|
+
----------------------------
|
3
|
+
|
4
|
+
Cukable comes with an executable script to convert existing Cucumber features
|
5
|
+
to FitNesse wiki format. You must have an existing FitNesse page; features will
|
6
|
+
be imported under that page.
|
7
|
+
|
8
|
+
Usage:
|
9
|
+
|
10
|
+
cuke2fit <features_path> <fitnesse_path>
|
11
|
+
|
12
|
+
For example, if your existing features are in `features/`, and the FitNesse
|
13
|
+
wiki page you want to import them to is in `FitNesseRoot/MyTests`, do:
|
14
|
+
|
15
|
+
$ cuke2fit features FitNesseRoot/MyTests
|
16
|
+
|
17
|
+
The hierarchy of your `features/` folder will be preserved as a hierarchy of
|
18
|
+
FitNesse wiki pages. Each `.feature` file becomes a separate wiki page.
|
19
|
+
|
20
|
+
Next: [Writing New Features](writing_features.md)
|
21
|
+
|
@@ -0,0 +1,28 @@
|
|
1
|
+
Cucumber arguments
|
2
|
+
------------------
|
3
|
+
|
4
|
+
There are two ways to pass command-line arguments to Cucumber when running
|
5
|
+
features. The first is by passing an argument directly to the `Cuke`
|
6
|
+
constructor in a feature table; just include an extra cell in the first row:
|
7
|
+
|
8
|
+
!| Table: Cuke | --tags @run_me |
|
9
|
+
| Feature: Arguments |
|
10
|
+
| @run_me |
|
11
|
+
| Scenario: This will be run |
|
12
|
+
| @dont_run_me |
|
13
|
+
| Scenario: This will be skipped |
|
14
|
+
|
15
|
+
This is the approach you'd use if you wanted to run a single test with
|
16
|
+
specific command-line arguments. If you want to run an entire suite using
|
17
|
+
the `AaaAccelerator` technique described above, you can define command-line
|
18
|
+
arguments as a FitNesse variable, like this:
|
19
|
+
|
20
|
+
!define CUCUMBER_ARGS {--tags @run_me}
|
21
|
+
|
22
|
+
Put this at the top of any suite page, and any `AaaAccelerator` in that suite
|
23
|
+
will pass those additional arguments to Cucumber. Note that these will override
|
24
|
+
any arguments passed to individual tables, because Cucumber is only executed
|
25
|
+
once for the entire suite.
|
26
|
+
|
27
|
+
Next: [Multiple Projects](multiple_projects.md)
|
28
|
+
|
data/docs/development.md
ADDED
@@ -0,0 +1,39 @@
|
|
1
|
+
Development
|
2
|
+
-----------
|
3
|
+
|
4
|
+
To hack on Cukable's code, first fork the
|
5
|
+
[repository](http://github.com/wapcaplet/cukable),
|
6
|
+
then clone your fork locally:
|
7
|
+
|
8
|
+
$ git clone git://github.com/your_username/cukable.git
|
9
|
+
|
10
|
+
Install [bundler](http://gembundler.com/):
|
11
|
+
|
12
|
+
$ gem install bundler
|
13
|
+
|
14
|
+
Then install Cukable's dependencies:
|
15
|
+
|
16
|
+
$ cd /path/to/cukable
|
17
|
+
$ bundle install
|
18
|
+
|
19
|
+
It's a good idea to use [RVM](http://rvm.beginrescueend.com/)
|
20
|
+
with a new gemset to keep things tidy.
|
21
|
+
|
22
|
+
If you make changes that you'd like to share, push them into your fork,
|
23
|
+
then [submit a pull request](http://github.com/wapcaplet/cukable/pulls).
|
24
|
+
|
25
|
+
|
26
|
+
Testing
|
27
|
+
-------
|
28
|
+
|
29
|
+
Cukable includes a suite of self-tests, executed using RSpec and Cucumber.
|
30
|
+
These are in the `spec` and `features` directories, respectively. To run the
|
31
|
+
full suite of tests, simply run:
|
32
|
+
|
33
|
+
$ rake
|
34
|
+
|
35
|
+
This will generate output showing the status of each test, and will also use
|
36
|
+
[rcov](http://eigenclass.org/hiki.rb?rcov) to write a code coverage report to
|
37
|
+
`coverage/index.html`.
|
38
|
+
|
39
|
+
|
data/docs/index.md
ADDED
@@ -0,0 +1,22 @@
|
|
1
|
+
Cukable
|
2
|
+
-------
|
3
|
+
|
4
|
+
Cukable allows you to write and execute [Cucumber](http://cukes.info) tests
|
5
|
+
from [FitNesse](http://fitnesse.org). It consists of a
|
6
|
+
[rubyslim](http://github.com/unclebob/rubyslim) fixture that invokes Cucumber,
|
7
|
+
and a custom Cucumber output formatter that returns SliM-formatted test results
|
8
|
+
to FitNesse.
|
9
|
+
|
10
|
+
- [Installation & Configuration](install.md)
|
11
|
+
- [Converting Existing Features](converting.md)
|
12
|
+
- [Writing New Features](writing_features.md)
|
13
|
+
- [Cukable Syntax](syntax.md)
|
14
|
+
- [Acceleration](accelerator.md)
|
15
|
+
- [Cucumber Arguments](cucumber_args.md)
|
16
|
+
- [Multiple Projects](multiple_projects.md)
|
17
|
+
- [Development & Testing](development.md)
|
18
|
+
- [MIT License](license.md)
|
19
|
+
|
20
|
+
Please report any bugs, complaints, and feature requests to the
|
21
|
+
[issue tracker](http://github.com/wapcaplet/cukable/issues).
|
22
|
+
|
data/docs/install.md
ADDED
@@ -0,0 +1,22 @@
|
|
1
|
+
Installation
|
2
|
+
------------
|
3
|
+
|
4
|
+
To install Cukable, simply do:
|
5
|
+
|
6
|
+
$ gem install cukable
|
7
|
+
|
8
|
+
|
9
|
+
Configuration
|
10
|
+
-------------
|
11
|
+
|
12
|
+
FitNesse uses a JSON format for its test reporting, so you must enable the SLIM
|
13
|
+
JSON output formatter provided by Cukable. To make Cucumber aware of this
|
14
|
+
formatter, add this line:
|
15
|
+
|
16
|
+
require 'cukable/slim_json_formatter'
|
17
|
+
|
18
|
+
to your `features/support/env.rb`, `features/support/custom_env.rb`, or
|
19
|
+
wherever you're keeping custom initialization for your Cucumber environment.
|
20
|
+
|
21
|
+
|
22
|
+
Next: [Converting Existing Features](converting.md)
|
data/docs/license.md
ADDED
@@ -0,0 +1,27 @@
|
|
1
|
+
MIT License
|
2
|
+
-----------
|
3
|
+
|
4
|
+
Cukable is licensed under the MIT License.
|
5
|
+
|
6
|
+
Copyright (c) 2011 Automation Excellence
|
7
|
+
|
8
|
+
Permission is hereby granted, free of charge, to any person obtaining
|
9
|
+
a copy of this software and associated documentation files (the
|
10
|
+
"Software"), to deal in the Software without restriction, including
|
11
|
+
without limitation the rights to use, copy, modify, merge, publish,
|
12
|
+
distribute, sublicense, and/or sell copies of the Software, and to
|
13
|
+
permit persons to whom the Software is furnished to do so, subject to
|
14
|
+
the following conditions:
|
15
|
+
|
16
|
+
The above copyright notice and this permission notice shall be
|
17
|
+
included in all copies or substantial portions of the Software.
|
18
|
+
|
19
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
20
|
+
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
21
|
+
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
22
|
+
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
23
|
+
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
24
|
+
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
25
|
+
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
26
|
+
|
27
|
+
|
@@ -0,0 +1,39 @@
|
|
1
|
+
Multiple projects
|
2
|
+
-----------------
|
3
|
+
|
4
|
+
As of Cukable version 0.1.2, you can run tests in multiple project directories.
|
5
|
+
For example, you may have two applications that you want to test with Cukable:
|
6
|
+
|
7
|
+
- `/home/eric/projects/A`: First application you want to test
|
8
|
+
- `/home/eric/projects/B`: Second application you want to test
|
9
|
+
- `/home/eric/projects/FitNesseRoot`: Where your wiki is stored
|
10
|
+
|
11
|
+
Projects `A` and `B` may have different dependencies, and you want Cukable to
|
12
|
+
mimic the process of running `cucumber` within each of those directories. If
|
13
|
+
`A` and `B` are Rails applications, and you know what's good for you, you're
|
14
|
+
already using [bundler](http://gembundler.com/) to manage each application's
|
15
|
+
gem dependencies, and [RVM](http://rvm.beginrescueend.com/) with two distinct
|
16
|
+
gemsets to keep the projects' dependencies from interfering with one another.
|
17
|
+
This is what Cukable expects that you are doing.
|
18
|
+
|
19
|
+
In your wiki pages (either in a `Cuke` table, or in the `accelerate` function
|
20
|
+
call), you can pass a third argument (after `CUCUMBER_ARGS`) that indicates the
|
21
|
+
directory where that test should be executed. For instance, you could have a
|
22
|
+
wiki page with two tests--one for each project:
|
23
|
+
|
24
|
+
!| Table: Cuke | | /home/eric/projects/A |
|
25
|
+
| When I run a test on project A |
|
26
|
+
| Then the test should pass |
|
27
|
+
|
28
|
+
!| Table: Cuke | | /home/eric/projects/B |
|
29
|
+
| When I run a different test on project B |
|
30
|
+
| Then the test should pass |
|
31
|
+
|
32
|
+
These two tests will be executed in their respective directories. If the two
|
33
|
+
applications have differing gem dependencies, you should put an `.rvmrc` file
|
34
|
+
in both the `A` and `B` directories, containing the correct `rvm` command to
|
35
|
+
switch gemsets; if Cukable finds an `.rvmrc` in a project directory, it will be
|
36
|
+
sourced so that Cucumber runs within the context of that gemset.
|
37
|
+
|
38
|
+
Next: [Development & Testing](development.md)
|
39
|
+
|
data/docs/syntax.md
ADDED
@@ -0,0 +1,117 @@
|
|
1
|
+
Supported syntax
|
2
|
+
----------------
|
3
|
+
|
4
|
+
Most of the standard Cucumber/Gherkin syntax is supported by Cukable, including:
|
5
|
+
|
6
|
+
- Background sections
|
7
|
+
- Scenarios and Scenario Outlines with Examples
|
8
|
+
- Multiple scenarios per feature
|
9
|
+
- Multi-line table arguments and table diffing
|
10
|
+
- Multi-line strings
|
11
|
+
- Tags for running/skipping scenarios and defining drivers (such as `@selenium`)
|
12
|
+
|
13
|
+
|
14
|
+
Test syntax
|
15
|
+
-----------
|
16
|
+
|
17
|
+
FitNesse uses wikitext tables delimited with a pipe `|` to format the
|
18
|
+
executable statements of a test scenario; these are rendered as HTML tables in
|
19
|
+
a FitNesse wiki page. When a test is run from FitNesse, the results of the test
|
20
|
+
are rendered into the same table, with green- or red-highlighted cells indicating
|
21
|
+
pass/fail status.
|
22
|
+
|
23
|
+
Cucumber tests written in a FitNesse wiki page closely resemble the
|
24
|
+
[Gherkin](http://github.com/aslakhellesoy/cucumber/wiki/gherkin) syntax that
|
25
|
+
Cucumber understands, with some changes in formatting to accommodate FitNesse.
|
26
|
+
|
27
|
+
If this is your `.feature` file:
|
28
|
+
|
29
|
+
Feature: Hello
|
30
|
+
Scenario: Hello world
|
31
|
+
Given I am on the hello page
|
32
|
+
Then I should see "Hello world"
|
33
|
+
|
34
|
+
Then here is what your FitNesse wikitext would be:
|
35
|
+
|
36
|
+
!| Table: Cuke |
|
37
|
+
| Feature: Hello |
|
38
|
+
| Scenario: Hello world |
|
39
|
+
| Given I am on the hello page |
|
40
|
+
| Then I should see "Hello world" |
|
41
|
+
|
42
|
+
Each row of the FitNesse table contains one step or other directive. Whitespace
|
43
|
+
before and/or after steps is not significant, so you can use it to aid
|
44
|
+
readability if you're into that sort of thing.
|
45
|
+
|
46
|
+
Your table must contain exactly one row with `Feature: ...`, and you must have
|
47
|
+
at least one `Scenario: ...` or `Scenario Outline: ...`.
|
48
|
+
|
49
|
+
|
50
|
+
Tables
|
51
|
+
------
|
52
|
+
|
53
|
+
Cucumber supports multiline step arguments in the form of tables; in a
|
54
|
+
`.feature` file, these might look like:
|
55
|
+
|
56
|
+
Feature: Tables
|
57
|
+
Scenario: Fill in fields
|
58
|
+
Given I am on the contact page
|
59
|
+
When I fill in the following:
|
60
|
+
| Name | Email | Message |
|
61
|
+
| Eric | wapcaplet88@gmail.com | Howdy |
|
62
|
+
|
63
|
+
In a FitNesse wiki page, this would translate to:
|
64
|
+
|
65
|
+
!| Table: Cuke |
|
66
|
+
| Feature: Tables |
|
67
|
+
| Scenario: Fill in fields |
|
68
|
+
| Given I am on the contact page |
|
69
|
+
| When I fill in the following: |
|
70
|
+
| | Name | Email | Message |
|
71
|
+
| | Eric | wapcaplet88@gmail.com | Howdy |
|
72
|
+
|
73
|
+
That is, each row in an embedded table begins with an empty cell. The same
|
74
|
+
applies to the "Examples" portion of a
|
75
|
+
[Scenario Outline](https://github.com/aslakhellesoy/cucumber/wiki/scenario-outlines):
|
76
|
+
|
77
|
+
| When I look at paint samples |
|
78
|
+
| Then I should see "<color>" |
|
79
|
+
| Examples: |
|
80
|
+
| | color |
|
81
|
+
| | Taupe |
|
82
|
+
| | Vermilion |
|
83
|
+
| | Fuscia |
|
84
|
+
|
85
|
+
|
86
|
+
Multi-line strings
|
87
|
+
------------------
|
88
|
+
|
89
|
+
To pass a multi-line string to one of your steps, just enter it as you normally
|
90
|
+
would in a .feature file, with triple-double-quotes delimiting the string:
|
91
|
+
|
92
|
+
| When I fill in "Message" with: |
|
93
|
+
| """ |
|
94
|
+
| So long, and |
|
95
|
+
| thanks for all the fish! |
|
96
|
+
| """ |
|
97
|
+
|
98
|
+
|
99
|
+
Tags
|
100
|
+
----
|
101
|
+
|
102
|
+
You can include Cucumber tags, as long as you only include one tag per row in
|
103
|
+
the table:
|
104
|
+
|
105
|
+
| @tag_a |
|
106
|
+
| @tag_b |
|
107
|
+
| Feature: Tagged feature |
|
108
|
+
| @tag_c |
|
109
|
+
| @tag_d |
|
110
|
+
| Scenario: Tagged scenario |
|
111
|
+
| When I have some tags |
|
112
|
+
|
113
|
+
The inclusion of tags is useful for defining which driver to use (for example
|
114
|
+
the `@selenium` tag supported by Capybara), as well as for controlling which
|
115
|
+
tests are run via cucumber command-line arguments, described below.
|
116
|
+
|
117
|
+
Next: [Acceleration](accelerator.md)
|
@@ -0,0 +1,48 @@
|
|
1
|
+
Writing new features
|
2
|
+
--------------------
|
3
|
+
|
4
|
+
You can write new Cucumber features from scratch, directly in FitNesse, and run
|
5
|
+
them from FitNesse with only minimal configuration.
|
6
|
+
|
7
|
+
Here's what a simple hierarchy might look like:
|
8
|
+
|
9
|
+
- FitNesseRoot
|
10
|
+
- CukableTests (suite)
|
11
|
+
- SetUp
|
12
|
+
- FeedKitty (test)
|
13
|
+
- CleanLitterbox (test)
|
14
|
+
|
15
|
+
Put these variable definitions in `CukableTests`:
|
16
|
+
|
17
|
+
!define TEST_SYSTEM {slim}
|
18
|
+
!define TEST_RUNNER {rubyslim}
|
19
|
+
!define COMMAND_PATTERN {rubyslim}
|
20
|
+
|
21
|
+
This is the essential configuration to tell FitNesse how to invoke `rubyslim`
|
22
|
+
for tests in the suite. Then put this in `CukableTests.SetUp`:
|
23
|
+
|
24
|
+
!| import |
|
25
|
+
| Cukable |
|
26
|
+
|
27
|
+
This tells `rubyslim` to load the `Cukable` module, so it'll know how to run
|
28
|
+
tests in `Cuke` tables. Now create a `Cuke` table in `CukableTests.FeedKitty`:
|
29
|
+
|
30
|
+
!| Table: Cuke |
|
31
|
+
| Feature: Feed kitty |
|
32
|
+
| Scenario: Canned food |
|
33
|
+
| Given I have a can of cat food |
|
34
|
+
| When I feed it to my cat |
|
35
|
+
| Then the cat should purr |
|
36
|
+
|
37
|
+
The `!` that precedes the table ensures that all text within will be treated
|
38
|
+
literally, and will not be marked up as FitNesse wiki-text. This is especially
|
39
|
+
important if you have CamelCase words, email addresses, or URLs in your table.
|
40
|
+
|
41
|
+
Also, note that all your steps must be defined in the usual way, such as `.rb`
|
42
|
+
files in `features/step_definitions`. That's outside Cukable's scope.
|
43
|
+
|
44
|
+
Finally, you can run the `FeedKitty` test by itself, or run the entire
|
45
|
+
`CukableTests` suite.
|
46
|
+
|
47
|
+
Next: [Cukable Syntax](syntax.md)
|
48
|
+
|
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: cukable
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 29
|
5
5
|
prerelease: false
|
6
6
|
segments:
|
7
7
|
- 0
|
8
8
|
- 1
|
9
|
-
-
|
10
|
-
version: 0.1.
|
9
|
+
- 3
|
10
|
+
version: 0.1.3
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Eric Pierce
|
@@ -16,7 +16,7 @@ autorequire:
|
|
16
16
|
bindir: bin
|
17
17
|
cert_chain: []
|
18
18
|
|
19
|
-
date: 2011-07-
|
19
|
+
date: 2011-07-22 00:00:00 -06:00
|
20
20
|
default_executable:
|
21
21
|
dependencies:
|
22
22
|
- !ruby/object:Gem::Dependency
|
@@ -62,9 +62,23 @@ dependencies:
|
|
62
62
|
type: :runtime
|
63
63
|
version_requirements: *id003
|
64
64
|
- !ruby/object:Gem::Dependency
|
65
|
-
name:
|
65
|
+
name: rubyslim-unofficial
|
66
66
|
prerelease: false
|
67
67
|
requirement: &id004 !ruby/object:Gem::Requirement
|
68
|
+
none: false
|
69
|
+
requirements:
|
70
|
+
- - ">="
|
71
|
+
- !ruby/object:Gem::Version
|
72
|
+
hash: 3
|
73
|
+
segments:
|
74
|
+
- 0
|
75
|
+
version: "0"
|
76
|
+
type: :runtime
|
77
|
+
version_requirements: *id004
|
78
|
+
- !ruby/object:Gem::Dependency
|
79
|
+
name: rake
|
80
|
+
prerelease: false
|
81
|
+
requirement: &id005 !ruby/object:Gem::Requirement
|
68
82
|
none: false
|
69
83
|
requirements:
|
70
84
|
- - ~>
|
@@ -76,11 +90,11 @@ dependencies:
|
|
76
90
|
- 7
|
77
91
|
version: 0.8.7
|
78
92
|
type: :development
|
79
|
-
version_requirements: *
|
93
|
+
version_requirements: *id005
|
80
94
|
- !ruby/object:Gem::Dependency
|
81
95
|
name: rspec
|
82
96
|
prerelease: false
|
83
|
-
requirement: &
|
97
|
+
requirement: &id006 !ruby/object:Gem::Requirement
|
84
98
|
none: false
|
85
99
|
requirements:
|
86
100
|
- - ">="
|
@@ -92,11 +106,11 @@ dependencies:
|
|
92
106
|
- 0
|
93
107
|
version: 2.2.0
|
94
108
|
type: :development
|
95
|
-
version_requirements: *
|
109
|
+
version_requirements: *id006
|
96
110
|
- !ruby/object:Gem::Dependency
|
97
111
|
name: rcov
|
98
112
|
prerelease: false
|
99
|
-
requirement: &
|
113
|
+
requirement: &id007 !ruby/object:Gem::Requirement
|
100
114
|
none: false
|
101
115
|
requirements:
|
102
116
|
- - ">="
|
@@ -106,11 +120,11 @@ dependencies:
|
|
106
120
|
- 0
|
107
121
|
version: "0"
|
108
122
|
type: :development
|
109
|
-
version_requirements: *
|
123
|
+
version_requirements: *id007
|
110
124
|
- !ruby/object:Gem::Dependency
|
111
125
|
name: yard
|
112
126
|
prerelease: false
|
113
|
-
requirement: &
|
127
|
+
requirement: &id008 !ruby/object:Gem::Requirement
|
114
128
|
none: false
|
115
129
|
requirements:
|
116
130
|
- - ">="
|
@@ -120,11 +134,11 @@ dependencies:
|
|
120
134
|
- 0
|
121
135
|
version: "0"
|
122
136
|
type: :development
|
123
|
-
version_requirements: *
|
137
|
+
version_requirements: *id008
|
124
138
|
- !ruby/object:Gem::Dependency
|
125
139
|
name: bluecloth
|
126
140
|
prerelease: false
|
127
|
-
requirement: &
|
141
|
+
requirement: &id009 !ruby/object:Gem::Requirement
|
128
142
|
none: false
|
129
143
|
requirements:
|
130
144
|
- - ">="
|
@@ -134,7 +148,7 @@ dependencies:
|
|
134
148
|
- 0
|
135
149
|
version: "0"
|
136
150
|
type: :development
|
137
|
-
version_requirements: *
|
151
|
+
version_requirements: *id009
|
138
152
|
description: " Cukable allows running Cucumber test scenarios from FitNesse\n"
|
139
153
|
email: wapcaplet88@gmail.com
|
140
154
|
executables:
|
@@ -152,6 +166,16 @@ files:
|
|
152
166
|
- Rakefile
|
153
167
|
- bin/cuke2fit
|
154
168
|
- cukable.gemspec
|
169
|
+
- docs/accelerator.md
|
170
|
+
- docs/converting.md
|
171
|
+
- docs/cucumber_args.md
|
172
|
+
- docs/development.md
|
173
|
+
- docs/index.md
|
174
|
+
- docs/install.md
|
175
|
+
- docs/license.md
|
176
|
+
- docs/multiple_projects.md
|
177
|
+
- docs/syntax.md
|
178
|
+
- docs/writing_features.md
|
155
179
|
- features/conversion.feature
|
156
180
|
- features/cuke_fixture.feature
|
157
181
|
- features/slim_json_formatter.feature
|
@@ -166,7 +190,6 @@ files:
|
|
166
190
|
- spec/cuke_spec.rb
|
167
191
|
- spec/helper_spec.rb
|
168
192
|
- spec/spec_helper.rb
|
169
|
-
- vendor/cache/rubyslim-0.1.1.gem
|
170
193
|
has_rdoc: true
|
171
194
|
homepage: http://github.com/wapcaplet/cukable
|
172
195
|
licenses: []
|
Binary file
|