rutabaga 0.0.1 → 0.0.2
Sign up to get free protection for your applications and to get access to all the features.
- data/.travis.yml +1 -1
- data/README.md +19 -15
- data/lib/rutabaga.rb +1 -0
- data/lib/rutabaga/rspec_scary_speed_fix.rb +11 -0
- data/lib/rutabaga/version.rb +1 -1
- metadata +3 -2
data/.travis.yml
CHANGED
data/README.md
CHANGED
@@ -2,7 +2,7 @@
|
|
2
2
|
|
3
3
|
Turnip hacks to enable running turnips from inside spec files, rather than outside.
|
4
4
|
|
5
|
-
Rutabaga allows you to invert the control of feature files, so that features are called from your `_spec.rb` files rather than the other way around. Step definitions are then put into the `_spec.rb` files as well.
|
5
|
+
Rutabaga allows you to invert the control of feature files, so that features are called from your `_spec.rb` files rather than the other way around. Step definitions are then put into the `_spec.rb` files as well. The steps are then scoped to that particular test.
|
6
6
|
|
7
7
|
This means that it is simple to create tests that are described by a class (such as controller tests in rspec-rails).
|
8
8
|
|
@@ -16,14 +16,14 @@ gem install rutabaga
|
|
16
16
|
|
17
17
|
Or add it to your Gemfile and run `bundle`.
|
18
18
|
|
19
|
-
```
|
19
|
+
```ruby
|
20
20
|
group :test do
|
21
|
-
gem "rutabaga"
|
21
|
+
gem "rutabaga"
|
22
22
|
end
|
23
23
|
```
|
24
24
|
|
25
25
|
Now edit the `.rspec` file in your project directory (create it if doesn't
|
26
|
-
exist), and add the following
|
26
|
+
exist), and add the following:
|
27
27
|
|
28
28
|
```
|
29
29
|
-r rutabaga
|
@@ -31,14 +31,14 @@ exist), and add the following line:
|
|
31
31
|
|
32
32
|
Add the follwing lines to the bottom of your `spec_helper.rb` (assuming you want to use Capybara and the final one if you wish to have step definitions outside of your spec files:
|
33
33
|
|
34
|
-
```
|
34
|
+
```ruby
|
35
35
|
require 'turnip/capybara'
|
36
36
|
Dir.glob("spec/features/step_definitions/**/*_steps.rb") { |f| load f, true }
|
37
37
|
```
|
38
38
|
|
39
39
|
In order to get `rake` or `bundle exec rake` to work properly, you might need to add this in the file `lib/tasks/rspec.rake` (at least for rails)
|
40
40
|
|
41
|
-
```
|
41
|
+
```ruby
|
42
42
|
if defined? RSpec # otherwise fails on non-live environments
|
43
43
|
desc "Run all specs/features in spec directory"
|
44
44
|
RSpec::Core::RakeTask.new(:spec => 'db:test:prepare') do |t|
|
@@ -55,7 +55,7 @@ Please look in `spec/controllers/feature_test_spec.rb` and `spec/controllers/fea
|
|
55
55
|
|
56
56
|
For file `spec/controllers/test_feature_spec.rb`
|
57
57
|
|
58
|
-
```
|
58
|
+
```ruby
|
59
59
|
it "should run feature" do
|
60
60
|
feature
|
61
61
|
end
|
@@ -63,7 +63,7 @@ end
|
|
63
63
|
|
64
64
|
Will run `spec/controllers/test_feature.feature`.
|
65
65
|
|
66
|
-
Features are found either with the same name as the spec file, or as specified in the example name `it "/path/to/feature/file.feature"`. So, if you have:
|
66
|
+
Features are found either with the same name as the spec file, or as specified in the example name `it "relative_from_root/path/to/feature/file.feature"`. So, if you have:
|
67
67
|
|
68
68
|
`spec/controllers/feature_test_spec.rb`
|
69
69
|
|
@@ -73,7 +73,7 @@ Then the feature will be:
|
|
73
73
|
|
74
74
|
Alternatively, if the feature is specified in the `it`, that takes precedence:
|
75
75
|
|
76
|
-
```
|
76
|
+
```ruby
|
77
77
|
it "spec/features/test.feature" do
|
78
78
|
feature
|
79
79
|
end
|
@@ -85,19 +85,23 @@ Will run `spec/features/test.feature`.
|
|
85
85
|
|
86
86
|
Other than these differences, Rutabaga is a tiny shim over Turnip and all features will work as expected.
|
87
87
|
|
88
|
-
* Turnip looks anywhere below the `spec` directory for `.feature` files. Rutabaga will only load `.feature` files from below the `spec/features` directory in the old way. This
|
88
|
+
* Turnip looks anywhere below the `spec` directory for `.feature` files. Rutabaga will only load `.feature` files from below the `spec/features` directory in the old way. This avoids conflicts with `.feature` files that are loaded from `_spec.rb` files.
|
89
89
|
|
90
90
|
## Why?
|
91
91
|
|
92
|
-
|
92
|
+
* Document business rules in Gherkin/Turnip/Cucumber human readable language
|
93
|
+
* Test those rules whereever/however appropriate (not just through Capybara/black box)
|
94
|
+
* Use the full power of RSpec (so being able to describe a class and then test it)
|
95
|
+
|
96
|
+
From my point of view, the fundamental purpose of Turnip/Cucumber is to document the system in end-user readable form. It is not just to do integration tests.
|
93
97
|
|
94
|
-
The most important functionality in a system is the business rules. These range from what appears on a page, to complex rules around when emails should be sent to who. For example, we've written Gherkin tests
|
98
|
+
The most important functionality in a system is the business rules. These range from what appears on a page, to complex rules around when emails should be sent to who. For example, we've written Gherkin tests to test premium changes when a customer changes their insurance coverage.
|
95
99
|
|
96
|
-
|
100
|
+
These rules are often implemented in a Model, a lib class, or some other specific class in the system, especially if the application is well modularized.
|
97
101
|
|
98
102
|
In any case, business rules are usually implemented somewhere inside a class tested by a unit test. I want to get those business rules tested in Cucumber/Turnip without having to go through the whole system, and without having to have duplicate tests, one inside my rspec and another inside my features.
|
99
103
|
|
100
|
-
My goal is to test just the business rule, in Turnip, and not the login, the html, the steps to get there, etc. That way, when the rule changes, I change the Turnip, the test code and the class in question. My test is not affected by wider ranging changes, and therefore less brittle.
|
104
|
+
My goal is to test just the business rule, in Turnip, and not the login, the html, the steps to get there, etc. That way, when the rule changes, I change the Turnip, the test code and the class in question. My test is not affected by wider ranging changes, and therefore less brittle. I guess, in that sense, the code runs at the unit code level, but is an acceptance test.
|
101
105
|
|
102
106
|
## Contributing
|
103
107
|
|
@@ -109,4 +113,4 @@ My goal is to test just the business rule, in Turnip, and not the login, the htm
|
|
109
113
|
|
110
114
|
## Copyright
|
111
115
|
|
112
|
-
Copyright © 2012
|
116
|
+
Copyright © 2012 Simply Business. See LICENSE for details.
|
data/lib/rutabaga.rb
CHANGED
data/lib/rutabaga/version.rb
CHANGED
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: rutabaga
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.0.
|
4
|
+
version: 0.0.2
|
5
5
|
prerelease:
|
6
6
|
platform: ruby
|
7
7
|
authors:
|
@@ -9,7 +9,7 @@ authors:
|
|
9
9
|
autorequire:
|
10
10
|
bindir: bin
|
11
11
|
cert_chain: []
|
12
|
-
date: 2012-08-
|
12
|
+
date: 2012-08-24 00:00:00.000000000 Z
|
13
13
|
dependencies:
|
14
14
|
- !ruby/object:Gem::Dependency
|
15
15
|
name: turnip
|
@@ -47,6 +47,7 @@ files:
|
|
47
47
|
- lib/.DS_Store
|
48
48
|
- lib/rutabaga.rb
|
49
49
|
- lib/rutabaga/feature.rb
|
50
|
+
- lib/rutabaga/rspec_scary_speed_fix.rb
|
50
51
|
- lib/rutabaga/version.rb
|
51
52
|
- rutabaga.gemspec
|
52
53
|
- spec/feature_spec.rb
|