rspec-given 1.6.0.beta.1 → 1.6.0
Sign up to get free protection for your applications and to get access to all the features.
- data/README +17 -0
- data/README.md +19 -0
- data/lib/rspec/given/version.rb +0 -2
- metadata +11 -12
- data/README.old +0 -264
data/README
CHANGED
@@ -179,6 +179,23 @@ The code block is executed once per test and the value of the code
|
|
179
179
|
block is bound to 'result'. Use this form when the code under test
|
180
180
|
returns a value that you wish to interrogate in the _Then_ code.
|
181
181
|
|
182
|
+
If an exception occurs during the execution of the When block, the
|
183
|
+
exception is caught and a failure object is bound to 'result'. The
|
184
|
+
failure can be checked in a then block with the 'have_failed' matcher.
|
185
|
+
|
186
|
+
The failure object will rethrow the captured exception if anything
|
187
|
+
other than have_failed matcher is used on the failure object.
|
188
|
+
|
189
|
+
For example, if the stack is empty when it is popped, then it is
|
190
|
+
reasonable for pop to raise an UnderflowError. This is how you might
|
191
|
+
specify that behavior:
|
192
|
+
|
193
|
+
When(:result) { stack.pop }
|
194
|
+
Then { result.should have_failed(UnderflowError, /empty/) }
|
195
|
+
|
196
|
+
Note that the arguments to the 'have_failed' matcher are the same as
|
197
|
+
those given to the standard RSpec matcher 'raise_error'.
|
198
|
+
|
182
199
|
=== Then
|
183
200
|
|
184
201
|
The _Then_ sections are the postconditions of the specification. These
|
data/README.md
CHANGED
@@ -193,6 +193,25 @@ The code block is executed once per test and the value of the code
|
|
193
193
|
block is bound to 'result'. Use this form when the code under test
|
194
194
|
returns a value that you wish to interrogate in the _Then_ code.
|
195
195
|
|
196
|
+
If an exception occurs during the execution of the When block, the
|
197
|
+
exception is caught and a failure object is bound to 'result'. The
|
198
|
+
failure can be checked in a then block with the 'have_failed' matcher.
|
199
|
+
|
200
|
+
The failure object will rethrow the captured exception if anything
|
201
|
+
other than have_failed matcher is used on the failure object.
|
202
|
+
|
203
|
+
For example, if the stack is empty when it is popped, then it is
|
204
|
+
reasonable for pop to raise an UnderflowError. This is how you might
|
205
|
+
specify that behavior:
|
206
|
+
|
207
|
+
<pre>
|
208
|
+
When(:result) { stack.pop }
|
209
|
+
Then { result.should have_failed(UnderflowError, /empty/) }
|
210
|
+
</pre>
|
211
|
+
|
212
|
+
Note that the arguments to the 'have_failed' matcher are the same as
|
213
|
+
those given to the standard RSpec matcher 'raise_error'.
|
214
|
+
|
196
215
|
### Then
|
197
216
|
|
198
217
|
The _Then_ sections are the postconditions of the specification. These
|
data/lib/rspec/given/version.rb
CHANGED
metadata
CHANGED
@@ -1,19 +1,19 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: rspec-given
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 1.6.0
|
5
|
-
prerelease:
|
4
|
+
version: 1.6.0
|
5
|
+
prerelease:
|
6
6
|
platform: ruby
|
7
7
|
authors:
|
8
8
|
- Jim Weirich
|
9
9
|
autorequire:
|
10
10
|
bindir: bin
|
11
11
|
cert_chain: []
|
12
|
-
date: 2012-08-
|
12
|
+
date: 2012-08-30 00:00:00.000000000 Z
|
13
13
|
dependencies:
|
14
14
|
- !ruby/object:Gem::Dependency
|
15
15
|
name: rspec
|
16
|
-
requirement: &
|
16
|
+
requirement: &70231666072020 !ruby/object:Gem::Requirement
|
17
17
|
none: false
|
18
18
|
requirements:
|
19
19
|
- - ! '>'
|
@@ -21,10 +21,10 @@ dependencies:
|
|
21
21
|
version: 1.2.8
|
22
22
|
type: :runtime
|
23
23
|
prerelease: false
|
24
|
-
version_requirements: *
|
24
|
+
version_requirements: *70231666072020
|
25
25
|
- !ruby/object:Gem::Dependency
|
26
26
|
name: bluecloth
|
27
|
-
requirement: &
|
27
|
+
requirement: &70231666071580 !ruby/object:Gem::Requirement
|
28
28
|
none: false
|
29
29
|
requirements:
|
30
30
|
- - ! '>='
|
@@ -32,10 +32,10 @@ dependencies:
|
|
32
32
|
version: '0'
|
33
33
|
type: :development
|
34
34
|
prerelease: false
|
35
|
-
version_requirements: *
|
35
|
+
version_requirements: *70231666071580
|
36
36
|
- !ruby/object:Gem::Dependency
|
37
37
|
name: rdoc
|
38
|
-
requirement: &
|
38
|
+
requirement: &70231666070900 !ruby/object:Gem::Requirement
|
39
39
|
none: false
|
40
40
|
requirements:
|
41
41
|
- - ! '>'
|
@@ -43,7 +43,7 @@ dependencies:
|
|
43
43
|
version: 2.4.2
|
44
44
|
type: :development
|
45
45
|
prerelease: false
|
46
|
-
version_requirements: *
|
46
|
+
version_requirements: *70231666070900
|
47
47
|
description: ! 'Given is an RSpec extension that allows explicit definition of the
|
48
48
|
|
49
49
|
pre and post-conditions for code under test.
|
@@ -58,7 +58,6 @@ files:
|
|
58
58
|
- Rakefile
|
59
59
|
- README
|
60
60
|
- README.md
|
61
|
-
- README.old
|
62
61
|
- lib/rspec-given.rb
|
63
62
|
- lib/rspec/given/configure.rb
|
64
63
|
- lib/rspec/given/extensions.rb
|
@@ -92,9 +91,9 @@ required_ruby_version: !ruby/object:Gem::Requirement
|
|
92
91
|
required_rubygems_version: !ruby/object:Gem::Requirement
|
93
92
|
none: false
|
94
93
|
requirements:
|
95
|
-
- - ! '
|
94
|
+
- - ! '>='
|
96
95
|
- !ruby/object:Gem::Version
|
97
|
-
version:
|
96
|
+
version: '0'
|
98
97
|
requirements: []
|
99
98
|
rubyforge_project: given
|
100
99
|
rubygems_version: 1.8.15
|
data/README.old
DELETED
@@ -1,264 +0,0 @@
|
|
1
|
-
# rspec-given
|
2
|
-
|
3
|
-
Covering rspec-given, version 1.5.1.
|
4
|
-
|
5
|
-
rspec-given is an RSpec extension to allow Given/When/Then notation in
|
6
|
-
RSpec specifications. It is a natural extension of the experimental
|
7
|
-
work done on the Given framework. It turns out that 90% of the Given
|
8
|
-
framework can be trivially implemented on top of RSpec.
|
9
|
-
|
10
|
-
# Why Given/When/Then
|
11
|
-
|
12
|
-
RSpec has done a great job of making specifications more readable for
|
13
|
-
humans. However, I really like the given / when / then nature of
|
14
|
-
Cucumber stories and would like to follow the same structure in my
|
15
|
-
unit tests. rspec-given allows a simple given/when/then structure
|
16
|
-
RSpec specifications.
|
17
|
-
|
18
|
-
## Status
|
19
|
-
|
20
|
-
_rspec-given_ is ready for production use.
|
21
|
-
|
22
|
-
## Example
|
23
|
-
|
24
|
-
Here is a specification written in the rspec-given framework:
|
25
|
-
|
26
|
-
<pre>
|
27
|
-
require 'rspec/given'
|
28
|
-
require 'spec_helper'
|
29
|
-
require 'stack'
|
30
|
-
|
31
|
-
describe Stack do
|
32
|
-
def stack_with(initial_contents)
|
33
|
-
stack = Stack.new
|
34
|
-
initial_contents.each do |item| stack.push(item) end
|
35
|
-
stack
|
36
|
-
end
|
37
|
-
|
38
|
-
Given(:stack) { stack_with(initial_contents) }
|
39
|
-
|
40
|
-
context "when empty" do
|
41
|
-
Given(:initial_contents) { [] }
|
42
|
-
Then { stack.depth.should == 0 }
|
43
|
-
|
44
|
-
context "when pushing" do
|
45
|
-
When { stack.push(:an_item) }
|
46
|
-
|
47
|
-
Then { stack.depth.should == 1 }
|
48
|
-
Then { stack.top.should == :an_item }
|
49
|
-
end
|
50
|
-
|
51
|
-
context "when popping" do
|
52
|
-
When(:result) { stack.pop }
|
53
|
-
Then { result.should have_failed(Stack::UnderflowError, /empty/) }
|
54
|
-
end
|
55
|
-
end
|
56
|
-
|
57
|
-
context "with one item" do
|
58
|
-
Given(:initial_contents) { [:an_item] }
|
59
|
-
|
60
|
-
context "when popping" do
|
61
|
-
When(:pop_result) { stack.pop }
|
62
|
-
|
63
|
-
Then { pop_result.should == :an_item }
|
64
|
-
Then { stack.should be_empty }
|
65
|
-
end
|
66
|
-
end
|
67
|
-
|
68
|
-
context "with several items" do
|
69
|
-
Given(:initial_contents) { [:second_item, :top_item] }
|
70
|
-
Given!(:original_depth) { stack.depth }
|
71
|
-
|
72
|
-
context "when pushing" do
|
73
|
-
When { stack.push(:new_item) }
|
74
|
-
|
75
|
-
Then { stack.top.should == :new_item }
|
76
|
-
Then { stack.depth.should == original_depth + 1 }
|
77
|
-
end
|
78
|
-
|
79
|
-
context "when popping" do
|
80
|
-
When(:pop_result) { stack.pop }
|
81
|
-
|
82
|
-
Then { pop_result.should == :top_item }
|
83
|
-
Then { stack.top.should == :second_item }
|
84
|
-
Then { stack.depth.should == original_depth - 1 }
|
85
|
-
end
|
86
|
-
end
|
87
|
-
end
|
88
|
-
</pre>
|
89
|
-
|
90
|
-
Let's talk about the individual statements used in the Given
|
91
|
-
framework.
|
92
|
-
|
93
|
-
### Given
|
94
|
-
|
95
|
-
The _Given_ section specifies a starting point, a set of preconditions
|
96
|
-
that must be true before the code under test is allowed to be run. In
|
97
|
-
standard test frameworks the preconditions are established with a
|
98
|
-
combination of setup methods (or :before actions in RSpec) and code in
|
99
|
-
the test.
|
100
|
-
|
101
|
-
In the example code above the preconditions are started with _Given_
|
102
|
-
statements. A top level _Given_ (that applies to the entire describe
|
103
|
-
block) says that one of the preconditions is that there is a stack
|
104
|
-
with some initial contents.
|
105
|
-
|
106
|
-
Note that initial contents are not specified in the top level describe
|
107
|
-
block, but are given in each of the nested contexts. By pushing the
|
108
|
-
definition of "initial_contents" into the nested contexts, we can vary
|
109
|
-
them as needed for that particular context.
|
110
|
-
|
111
|
-
A precondition in the form "Given(:var) {...}" creates an accessor
|
112
|
-
method named "var". The accessor is lazily initialized by the code
|
113
|
-
block. If you want a non-lazy given, use "Given!(:var) {...}".
|
114
|
-
|
115
|
-
A precondition in the form "Given {...}" just executes the code block
|
116
|
-
for side effects. Since there is no accessor, the code block is
|
117
|
-
executed immediately (i.e. no lazy evaluation).
|
118
|
-
|
119
|
-
The preconditions are run in order of definition. Nested contexts
|
120
|
-
will inherit the preconditions from the enclosing context, with out
|
121
|
-
preconditions running before inner preconditions.
|
122
|
-
|
123
|
-
#### Given examples:
|
124
|
-
|
125
|
-
<pre>
|
126
|
-
Given(:stack) { Stack.new }
|
127
|
-
</pre>
|
128
|
-
|
129
|
-
The given block is lazily run if 'stack' is ever referenced in the
|
130
|
-
test and the value of the block is bound to 'stack'. The first
|
131
|
-
reference to 'stack' in the specification will cause the code block to
|
132
|
-
execute. Futher references to 'stack' will reuse the previously
|
133
|
-
generated value.
|
134
|
-
|
135
|
-
<pre>
|
136
|
-
Given!(:original_size) { stack.size }
|
137
|
-
</pre>
|
138
|
-
|
139
|
-
The code block is run unconditionally once before each test and the
|
140
|
-
value of the block is bound to 'original_size'. This form is useful
|
141
|
-
when you want to record the value of something that might be affected
|
142
|
-
by the When code.
|
143
|
-
|
144
|
-
<pre>
|
145
|
-
Given { stack.clear }
|
146
|
-
</pre>
|
147
|
-
|
148
|
-
The given block is run unconditionally once before each test. This
|
149
|
-
form of given is used for code that is executed for side effects.
|
150
|
-
|
151
|
-
### When
|
152
|
-
|
153
|
-
The _When_ block specifies the code to be tested ... oops, excuse me
|
154
|
-
... specified. After the preconditions in the given section are met,
|
155
|
-
the when code block is run.
|
156
|
-
|
157
|
-
There should only be one _When_ block for a given context. However, a
|
158
|
-
_When_ in an outer context shoud be treated as a _Given_ in an inner
|
159
|
-
context. E.g.
|
160
|
-
|
161
|
-
<pre>
|
162
|
-
context "outer context" do
|
163
|
-
When { code specified in the outer context }
|
164
|
-
Then { assert something about the outer context }
|
165
|
-
|
166
|
-
context "inner context" do
|
167
|
-
|
168
|
-
# At this point, the _When_ of the outer context
|
169
|
-
# should be treated as a _Given_ of the inner context
|
170
|
-
|
171
|
-
When { code specified in the inner context }
|
172
|
-
Then { assert something about the inner context }
|
173
|
-
end
|
174
|
-
end
|
175
|
-
</pre>
|
176
|
-
|
177
|
-
#### When examples:
|
178
|
-
|
179
|
-
<pre>
|
180
|
-
When { stack.push(:item) }
|
181
|
-
</pre>
|
182
|
-
|
183
|
-
The code block is executed once per test. The effect of the _When{}_
|
184
|
-
block is very similar to _Given{}_. However, When is used to identify
|
185
|
-
the particular code that is being specified in the current context or
|
186
|
-
describe block.
|
187
|
-
|
188
|
-
<pre>
|
189
|
-
When(:result) { stack.pop }
|
190
|
-
</pre>
|
191
|
-
|
192
|
-
The code block is executed once per test and the value of the code
|
193
|
-
block is bound to 'result'. Use this form when the code under test
|
194
|
-
returns a value that you wish to interrogate in the _Then_ code.
|
195
|
-
|
196
|
-
### Then
|
197
|
-
|
198
|
-
The _Then_ sections are the postconditions of the specification. These
|
199
|
-
then conditions must be true after the code under test (the _When_
|
200
|
-
block) is run.
|
201
|
-
|
202
|
-
The code in the _Then_ block should be a single _should_
|
203
|
-
assertion. Code in _Then_ blocks should not have any side effects.
|
204
|
-
|
205
|
-
#### Then examples:
|
206
|
-
|
207
|
-
<pre>
|
208
|
-
Then { stack.should be_empty }
|
209
|
-
</pre>
|
210
|
-
|
211
|
-
After the related _When_ block is run, the stack should be empty. If
|
212
|
-
it is not empty, the test will fail.
|
213
|
-
|
214
|
-
<!--
|
215
|
-
### Invariant
|
216
|
-
|
217
|
-
The _Invariant_ block is a new idea that doesn't have an analog in
|
218
|
-
RSpec or Test::Unit. The invariant allows you specify things that
|
219
|
-
must always be true. In the stack example, <tt>empty?</tt> is defined
|
220
|
-
in term of <tt>size</tt>. Whenever <tt>size</tt> is 0,
|
221
|
-
<tt>empty?</tt> should be true. Whenever <tt>size</tt> is non-zero,
|
222
|
-
<tt>empty?</tt> should be false.
|
223
|
-
|
224
|
-
You can conceptually think of an _Invariant_ block as a _Then_ block
|
225
|
-
that automatically gets added to every _When_ within its scope.
|
226
|
-
|
227
|
-
Invariants nested within a context only apply to the _When_ blocks in
|
228
|
-
that context.
|
229
|
-
|
230
|
-
Invariants that reference a _Given_ precondition accessor must only be
|
231
|
-
used in contexts that define that accessor.
|
232
|
-
|
233
|
-
NOTE: Invariants are not yet implemented in the current version of
|
234
|
-
rspec-given.
|
235
|
-
|
236
|
-
-->
|
237
|
-
|
238
|
-
# Future Directions
|
239
|
-
|
240
|
-
I really like the way the Given framework is working out. I feel my
|
241
|
-
tests are much more like specifications when I use it. However, I'm
|
242
|
-
not entirely happy with it.
|
243
|
-
|
244
|
-
First, I would like to introduce invariants. An _Invariant_ block
|
245
|
-
would essentially be a post-conditions that should be true after
|
246
|
-
_Then_ block in the same (or nested) context as the invariant.
|
247
|
-
|
248
|
-
Second, I would like to remove the need for the ".should" in all the
|
249
|
-
_Then_ blocks. In other words, instead of saying:
|
250
|
-
|
251
|
-
Then { x.should == y }
|
252
|
-
|
253
|
-
we could say:
|
254
|
-
|
255
|
-
Then { x == y }
|
256
|
-
|
257
|
-
I think the [wrong assertion library](http://rubygems.org/gems/wrong)
|
258
|
-
has laid some groundwork in this area.
|
259
|
-
|
260
|
-
# Links
|
261
|
-
|
262
|
-
* Github: [https://github.com/jimweirich/rspec-given](https://github.com/jimweirich/rspec-given)
|
263
|
-
* Clone URL: git://github.com/jimweirich/rspec-given.git
|
264
|
-
* Bug/Issue Reporting: [https://github.com/jimweirich/rspec-given/issues](https://github.com/jimweirich/rspec-given/issues)
|