cucumber 0.5.2 → 0.5.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/History.txt +7 -0
- data/VERSION.yml +1 -1
- data/cucumber.gemspec +2 -2
- data/features/wire_protocol.feature +101 -68
- data/features/wire_protocol_table_diffing.feature +18 -21
- data/features/wire_protocol_timeouts.feature +6 -6
- data/lib/cucumber/wire_support/request_handler.rb +3 -0
- data/lib/cucumber/wire_support/wire_packet.rb +4 -2
- data/lib/cucumber/wire_support/wire_protocol/requests.rb +21 -33
- data/spec/cucumber/wire_support/wire_packet_spec.rb +19 -5
- metadata +2 -2
data/History.txt
CHANGED
data/VERSION.yml
CHANGED
data/cucumber.gemspec
CHANGED
@@ -5,7 +5,7 @@
|
|
5
5
|
|
6
6
|
Gem::Specification.new do |s|
|
7
7
|
s.name = %q{cucumber}
|
8
|
-
s.version = "0.5.
|
8
|
+
s.version = "0.5.3"
|
9
9
|
|
10
10
|
s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
|
11
11
|
s.authors = ["Aslak Helles\303\270y"]
|
@@ -544,7 +544,7 @@ Gem::Specification.new do |s|
|
|
544
544
|
|
545
545
|
(::) U P G R A D I N G (::)
|
546
546
|
|
547
|
-
Thank you for installing cucumber-0.5.
|
547
|
+
Thank you for installing cucumber-0.5.3.
|
548
548
|
Please be sure to read http://wiki.github.com/aslakhellesoy/cucumber/upgrading
|
549
549
|
for important information about this release. Happy cuking!
|
550
550
|
|
@@ -13,18 +13,28 @@ Feature: Wire Protocol
|
|
13
13
|
# a definition file with the .wire extension in the step_definitions folder
|
14
14
|
# (or other load path).
|
15
15
|
#
|
16
|
-
# Cucumber
|
16
|
+
# Cucumber sends the following request messages out over the wire:
|
17
17
|
#
|
18
|
-
# * step_matches : this is used to find out whether the wire
|
18
|
+
# * step_matches : this is used to find out whether the wire server has a
|
19
19
|
# definition for a given step
|
20
20
|
# * invoke : this is used to ask for a step definition to be invoked
|
21
21
|
# * begin_scenario : signals that cucumber is about to execute a scenario
|
22
22
|
# * end_scenario : signals that cucumber has finished executing a scenario
|
23
23
|
# * snippet_text : requests a snippet for an undefined step
|
24
24
|
#
|
25
|
-
#
|
26
|
-
#
|
27
|
-
#
|
25
|
+
# Every message supports two standard responses:
|
26
|
+
# * success : which expects different arguments (sometimes none at
|
27
|
+
# depending on the request.
|
28
|
+
# * fail : causes a Cucumber::WireSupport::WireException to be
|
29
|
+
# raised.
|
30
|
+
#
|
31
|
+
# Some messages support more responses - see below for details.
|
32
|
+
#
|
33
|
+
# A WirePacket flowing in either direction is formatted as a JSON-encoded
|
34
|
+
# string, with a newline character signalling the end of a packet. See the
|
35
|
+
# specs for Cucumber::WireSupport::WirePacket for more details.
|
36
|
+
#
|
37
|
+
# These messages are described in detail below, with examples.
|
28
38
|
#
|
29
39
|
|
30
40
|
Background:
|
@@ -44,19 +54,18 @@ Feature: Wire Protocol
|
|
44
54
|
|
45
55
|
|
46
56
|
#
|
47
|
-
# step_matches
|
57
|
+
# # Request: 'step_matches'
|
48
58
|
#
|
49
59
|
# When the features have been parsed, Cucumber will send a step_matches
|
50
|
-
# message to ask the wire
|
60
|
+
# message to ask the wire server if it can match a step name. This happens for
|
51
61
|
# each of the steps in each of the features.
|
52
62
|
#
|
53
|
-
# The wire
|
54
|
-
# definitions that could be invoked for the given step name.
|
63
|
+
# The wire server replies with an array of StepMatch objects.
|
55
64
|
|
56
65
|
Scenario: Dry run finds no step match
|
57
66
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
58
|
-
| request | response
|
59
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
67
|
+
| request | response |
|
68
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
60
69
|
When I run cucumber --dry-run -f progress
|
61
70
|
And it should pass with
|
62
71
|
"""
|
@@ -67,17 +76,16 @@ Feature: Wire Protocol
|
|
67
76
|
|
68
77
|
"""
|
69
78
|
|
70
|
-
# When
|
71
|
-
# definition to be used later when
|
72
|
-
#
|
73
|
-
#
|
74
|
-
#
|
75
|
-
#
|
76
|
-
# end's own regular expression or other argument matching process.
|
79
|
+
# When each StepMatch is returned, it contains the following data:
|
80
|
+
# * id - identifier for the step definition to be used later when if it
|
81
|
+
# needs to be invoked. The identifier can be any string value and
|
82
|
+
# is simply used for the wire server's own reference.
|
83
|
+
# * args - any argument values as captured by the wire end's own regular
|
84
|
+
# expression (or other argument matching) process.
|
77
85
|
Scenario: Dry run finds a step match
|
78
86
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
79
|
-
| request | response
|
80
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
87
|
+
| request | response |
|
88
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
81
89
|
When I run cucumber --dry-run -f progress
|
82
90
|
And it should pass with
|
83
91
|
"""
|
@@ -88,12 +96,12 @@ Feature: Wire Protocol
|
|
88
96
|
|
89
97
|
"""
|
90
98
|
|
91
|
-
# Optionally, the
|
92
|
-
#
|
99
|
+
# Optionally, the StepMatch can also contain a source reference, and a native
|
100
|
+
# regexp string which will be used by some formatters.
|
93
101
|
Scenario: Step matches returns details about the remote step definition
|
94
102
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
95
|
-
| request | response
|
96
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
103
|
+
| request | response |
|
104
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
|
97
105
|
When I run cucumber -f stepdefs --dry-run
|
98
106
|
Then STDERR should be empty
|
99
107
|
And it should pass with
|
@@ -109,25 +117,33 @@ Feature: Wire Protocol
|
|
109
117
|
|
110
118
|
|
111
119
|
#
|
112
|
-
# invoke
|
120
|
+
# # Request: 'invoke'
|
113
121
|
#
|
114
|
-
# Assuming a
|
122
|
+
# Assuming a StepMatch was returned for a given step name, when it's time to
|
115
123
|
# invoke that step definition, Cucumber will send an invoke message.
|
116
124
|
#
|
117
|
-
# The message contains the ID of the step definition, as returned by
|
118
|
-
#
|
119
|
-
# from the step name during the same step_matches
|
125
|
+
# The invoke message contains the ID of the step definition, as returned by
|
126
|
+
# the wire server in response to the the step_matches call, along with the
|
127
|
+
# arguments that were parsed from the step name during the same step_matches
|
128
|
+
# call.
|
129
|
+
#
|
130
|
+
# The wire server will normally[1] reply one of the following:
|
131
|
+
# * success
|
132
|
+
# * fail
|
133
|
+
# * pending : optionally takes a message argument
|
134
|
+
#
|
135
|
+
# [1] This isn't the whole story: see also wire_protocol_table_diffing.feature
|
120
136
|
#
|
121
|
-
# The wire end will reply with either a step_failed, success, or pending message.
|
122
137
|
|
123
|
-
#
|
138
|
+
# ## Pending Steps
|
139
|
+
#
|
124
140
|
Scenario: Invoke a step definition which is pending
|
125
141
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
126
|
-
| request | response
|
127
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
128
|
-
| ["begin_scenario"
|
129
|
-
| ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"]
|
130
|
-
| ["end_scenario"
|
142
|
+
| request | response |
|
143
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
144
|
+
| ["begin_scenario"] | ["success"] |
|
145
|
+
| ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"] |
|
146
|
+
| ["end_scenario"] | ["success"] |
|
131
147
|
When I run cucumber -f pretty -q
|
132
148
|
And it should pass with
|
133
149
|
"""
|
@@ -143,13 +159,15 @@ Feature: Wire Protocol
|
|
143
159
|
|
144
160
|
"""
|
145
161
|
|
162
|
+
# ## Passing Steps
|
163
|
+
#
|
146
164
|
Scenario: Invoke a step definition which passes
|
147
165
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
148
|
-
| request | response
|
149
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
150
|
-
| ["begin_scenario"
|
151
|
-
| ["invoke",{"id":"1","args":[]}] | ["success"
|
152
|
-
| ["end_scenario"
|
166
|
+
| request | response |
|
167
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
168
|
+
| ["begin_scenario"] | ["success"] |
|
169
|
+
| ["invoke",{"id":"1","args":[]}] | ["success"] |
|
170
|
+
| ["end_scenario"] | ["success"] |
|
153
171
|
When I run cucumber -f progress
|
154
172
|
And it should pass with
|
155
173
|
"""
|
@@ -160,17 +178,26 @@ Feature: Wire Protocol
|
|
160
178
|
|
161
179
|
"""
|
162
180
|
|
181
|
+
# ## Failing Steps
|
182
|
+
#
|
163
183
|
# When an invoked step definition fails, it can return details of the exception
|
164
|
-
# in the reply to invoke.
|
165
|
-
#
|
184
|
+
# in the reply to invoke. This causes a Cucumber::WireSupport::WireException to be
|
185
|
+
# raised.
|
186
|
+
#
|
187
|
+
# Valid arguments are:
|
188
|
+
# * message (mandatory)
|
189
|
+
# * exception
|
190
|
+
# * backtrace
|
191
|
+
#
|
192
|
+
# See the specs for Cucumber::WireSupport::WireException for more details
|
166
193
|
#
|
167
194
|
Scenario: Invoke a step definition which fails
|
168
195
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
169
|
-
| request | response
|
170
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
171
|
-
| ["begin_scenario"
|
172
|
-
| ["invoke",{"id":"1","args":[]}] | ["
|
173
|
-
| ["end_scenario"
|
196
|
+
| request | response |
|
197
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
198
|
+
| ["begin_scenario"] | ["success"] |
|
199
|
+
| ["invoke",{"id":"1","args":[]}] | ["fail",{"message":"The wires are down", "exception":"Some.Foreign.ExceptionType"}] |
|
200
|
+
| ["end_scenario"] | ["success"] |
|
174
201
|
When I run cucumber -f progress
|
175
202
|
Then STDERR should be empty
|
176
203
|
And it should fail with
|
@@ -190,13 +217,15 @@ Feature: Wire Protocol
|
|
190
217
|
|
191
218
|
"""
|
192
219
|
|
220
|
+
# ## Step Arguments
|
221
|
+
#
|
193
222
|
# Imagine we have a step definition like:
|
194
223
|
#
|
195
224
|
# Given /we're all (.*)/ do | what_we_are |
|
196
225
|
# end
|
197
226
|
#
|
198
227
|
# When this step definition matches the step name in our feature, the word
|
199
|
-
# 'wired' will be
|
228
|
+
# 'wired' will be captured as an argument.
|
200
229
|
#
|
201
230
|
# Cucumber expects this StepArgument to be returned in the StepMatch. The keys
|
202
231
|
# have the following meanings:
|
@@ -207,11 +236,11 @@ Feature: Wire Protocol
|
|
207
236
|
#
|
208
237
|
Scenario: Invoke a step definition which takes string arguments (and passes)
|
209
238
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
210
|
-
| request | response
|
211
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
212
|
-
| ["begin_scenario"
|
213
|
-
| ["invoke",{"id":"1","args":["wired"]}] | ["success"
|
214
|
-
| ["end_scenario"
|
239
|
+
| request | response |
|
240
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
|
241
|
+
| ["begin_scenario"] | ["success"] |
|
242
|
+
| ["invoke",{"id":"1","args":["wired"]}] | ["success"] |
|
243
|
+
| ["end_scenario"] | ["success"] |
|
215
244
|
When I run cucumber -f progress
|
216
245
|
Then STDERR should be empty
|
217
246
|
And it should pass with
|
@@ -223,6 +252,8 @@ Feature: Wire Protocol
|
|
223
252
|
|
224
253
|
"""
|
225
254
|
|
255
|
+
# ## Multiline Table Arguments
|
256
|
+
#
|
226
257
|
# When the step has a multiline table argument, it will be passed with the
|
227
258
|
# invoke message as a string - a serialized JSON array of array of strings.
|
228
259
|
# In the following scenario our step definition takes two arguments - one
|
@@ -237,11 +268,11 @@ Feature: Wire Protocol
|
|
237
268
|
| happy |
|
238
269
|
"""
|
239
270
|
And there is a wire server running on port 54321 which understands the following protocol:
|
240
|
-
| request | response
|
241
|
-
| ["step_matches",{"name_to_match":"we're all:"}] | ["
|
242
|
-
| ["begin_scenario"
|
243
|
-
| ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success"
|
244
|
-
| ["end_scenario"
|
271
|
+
| request | response |
|
272
|
+
| ["step_matches",{"name_to_match":"we're all:"}] | ["success",[{"id":"1", "args":[{"val":"we're", "pos":0}]}]] |
|
273
|
+
| ["begin_scenario"] | ["success"] |
|
274
|
+
| ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success"] |
|
275
|
+
| ["end_scenario"] | ["success"] |
|
245
276
|
When I run cucumber -f progress features/wired_on_tables.feature
|
246
277
|
Then STDERR should be empty
|
247
278
|
And it should pass with
|
@@ -255,15 +286,15 @@ Feature: Wire Protocol
|
|
255
286
|
|
256
287
|
|
257
288
|
#
|
258
|
-
# snippets
|
289
|
+
# # Request: 'snippets'
|
259
290
|
#
|
260
291
|
Scenario: Wire server returns snippets for a step that didn't match
|
261
292
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
262
|
-
| request | response
|
263
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
264
|
-
| ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["
|
265
|
-
| ["begin_scenario"
|
266
|
-
| ["end_scenario"
|
293
|
+
| request | response |
|
294
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
295
|
+
| ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["success","foo()\n bar;\nbaz"] |
|
296
|
+
| ["begin_scenario"] | ["success"] |
|
297
|
+
| ["end_scenario"] | ["success"] |
|
267
298
|
When I run cucumber -f pretty
|
268
299
|
And it should pass with
|
269
300
|
"""
|
@@ -284,11 +315,13 @@ Feature: Wire Protocol
|
|
284
315
|
|
285
316
|
"""
|
286
317
|
|
287
|
-
|
318
|
+
#
|
319
|
+
# # Bad Response
|
320
|
+
#
|
288
321
|
Scenario: Unexpected response
|
289
322
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
290
|
-
| request
|
291
|
-
| ["begin_scenario"
|
323
|
+
| request | response |
|
324
|
+
| ["begin_scenario"] | ["yikes"] |
|
292
325
|
When I run cucumber -f progress
|
293
326
|
Then STDERR should match
|
294
327
|
"""
|
@@ -21,12 +21,12 @@ Feature: Wire protocol table diffing
|
|
21
21
|
|
22
22
|
Scenario: Invoke a step definition tries to diff the table and fails
|
23
23
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
24
|
-
| request | response
|
25
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
26
|
-
| ["begin_scenario"
|
27
|
-
| ["invoke",{"id":"1","args":[]}] | ["diff",[[["a","b"],["c","d"]],[["x","y"],["z","z"]]]]
|
28
|
-
| ["diff_failed"
|
29
|
-
| ["end_scenario"
|
24
|
+
| request | response |
|
25
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
26
|
+
| ["begin_scenario"] | ["success"] |
|
27
|
+
| ["invoke",{"id":"1","args":[]}] | ["diff",[[["a","b"],["c","d"]],[["x","y"],["z","z"]]]] |
|
28
|
+
| ["diff_failed"] | ["fail",{"message":"Not same", "exception":"DifferentException", "backtrace":["a.cs:12","b.cs:34"]}] |
|
29
|
+
| ["end_scenario"] | ["success"] |
|
30
30
|
When I run cucumber -f progress --backtrace
|
31
31
|
And it should fail with
|
32
32
|
"""
|
@@ -49,12 +49,12 @@ Feature: Wire protocol table diffing
|
|
49
49
|
|
50
50
|
Scenario: Invoke a step definition tries to diff the table and passes
|
51
51
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
52
|
-
| request | response
|
53
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
54
|
-
| ["begin_scenario"
|
55
|
-
| ["invoke",{"id":"1","args":[]}] | ["diff",[[["a"],["b"]],[["a"],["b"]]]]
|
56
|
-
| ["diff_ok"
|
57
|
-
| ["end_scenario"
|
52
|
+
| request | response |
|
53
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
54
|
+
| ["begin_scenario"] | ["success"] |
|
55
|
+
| ["invoke",{"id":"1","args":[]}] | ["diff",[[["a"],["b"]],[["a"],["b"]]]] |
|
56
|
+
| ["diff_ok"] | ["success"] |
|
57
|
+
| ["end_scenario"] | ["success"] |
|
58
58
|
When I run cucumber -f progress
|
59
59
|
And it should pass with
|
60
60
|
"""
|
@@ -67,12 +67,12 @@ Feature: Wire protocol table diffing
|
|
67
67
|
|
68
68
|
Scenario: Invoke a step definition which successfully diffs a table but then fails
|
69
69
|
Given there is a wire server running on port 54321 which understands the following protocol:
|
70
|
-
| request | response
|
71
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
72
|
-
| ["begin_scenario"
|
73
|
-
| ["invoke",{"id":"1","args":[]}] | ["diff",[[["a"],["b"]],[["a"],["b"]]]]
|
74
|
-
| ["diff_ok"
|
75
|
-
| ["end_scenario"
|
70
|
+
| request | response |
|
71
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
72
|
+
| ["begin_scenario"] | ["success"] |
|
73
|
+
| ["invoke",{"id":"1","args":[]}] | ["diff",[[["a"],["b"]],[["a"],["b"]]]] |
|
74
|
+
| ["diff_ok"] | ["fail",{"message":"I wanted things to be different for us"}] |
|
75
|
+
| ["end_scenario"] | ["success"] |
|
76
76
|
When I run cucumber -f progress
|
77
77
|
And it should fail with
|
78
78
|
"""
|
@@ -90,6 +90,3 @@ Feature: Wire protocol table diffing
|
|
90
90
|
1 step (1 failed)
|
91
91
|
|
92
92
|
"""
|
93
|
-
|
94
|
-
|
95
|
-
|
@@ -36,11 +36,11 @@ Feature: Wire protocol timeouts
|
|
36
36
|
|
37
37
|
"""
|
38
38
|
And there is a wire server on port 54321 which understands the following protocol:
|
39
|
-
| request | response
|
40
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["
|
41
|
-
| ["begin_scenario"
|
42
|
-
| ["invoke",{"id":"1","args":["wired"]}] | ["success"
|
43
|
-
| ["end_scenario"
|
39
|
+
| request | response |
|
40
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
|
41
|
+
| ["begin_scenario"] | ["success"] |
|
42
|
+
| ["invoke",{"id":"1","args":["wired"]}] | ["success"] |
|
43
|
+
| ["end_scenario"] | ["success"] |
|
44
44
|
And the wire server takes 0.2 seconds to respond to the invoke message
|
45
45
|
When I run cucumber -f pretty
|
46
46
|
Then STDERR should be empty
|
@@ -59,4 +59,4 @@ Feature: Wire protocol timeouts
|
|
59
59
|
1 scenario (1 failed)
|
60
60
|
1 step (1 failed)
|
61
61
|
|
62
|
-
"""
|
62
|
+
"""
|
@@ -14,12 +14,14 @@ module Cucumber
|
|
14
14
|
|
15
15
|
attr_reader :message, :params
|
16
16
|
|
17
|
-
def initialize(message, params)
|
17
|
+
def initialize(message, params = nil)
|
18
18
|
@message, @params = message, params
|
19
19
|
end
|
20
20
|
|
21
21
|
def to_json
|
22
|
-
[@message
|
22
|
+
packet = [@message]
|
23
|
+
packet << @params if @params
|
24
|
+
packet.to_json
|
23
25
|
end
|
24
26
|
|
25
27
|
def handle_with(handler)
|
@@ -12,17 +12,23 @@ module Cucumber
|
|
12
12
|
super(request_params)
|
13
13
|
end
|
14
14
|
|
15
|
-
def
|
15
|
+
def handle_success(params)
|
16
16
|
params.map do |raw_step_match|
|
17
|
-
|
18
|
-
step_args = raw_step_match['args'].map do |raw_arg|
|
19
|
-
StepArgument.new(raw_arg['val'], raw_arg['pos'])
|
20
|
-
end
|
21
|
-
step_match(step_definition, step_args)
|
17
|
+
create_step_match(raw_step_match)
|
22
18
|
end
|
23
19
|
end
|
20
|
+
|
21
|
+
alias :handle_step_matches :handle_success
|
24
22
|
|
25
23
|
private
|
24
|
+
|
25
|
+
def create_step_match(raw_step_match)
|
26
|
+
step_definition = WireStepDefinition.new(@connection, raw_step_match)
|
27
|
+
step_args = raw_step_match['args'].map do |raw_arg|
|
28
|
+
StepArgument.new(raw_arg['val'], raw_arg['pos'])
|
29
|
+
end
|
30
|
+
step_match(step_definition, step_args)
|
31
|
+
end
|
26
32
|
|
27
33
|
def step_match(step_definition, step_args)
|
28
34
|
StepMatch.new(step_definition, @name_to_match, @name_to_report, step_args)
|
@@ -38,10 +44,12 @@ module Cucumber
|
|
38
44
|
}
|
39
45
|
super(request_params)
|
40
46
|
end
|
41
|
-
|
42
|
-
def
|
43
|
-
|
47
|
+
|
48
|
+
def handle_success(snippet_text)
|
49
|
+
snippet_text
|
44
50
|
end
|
51
|
+
|
52
|
+
alias :handle_snippet_text :handle_success
|
45
53
|
end
|
46
54
|
|
47
55
|
class Invoke < RequestHandler
|
@@ -53,9 +61,6 @@ module Cucumber
|
|
53
61
|
super(request_params)
|
54
62
|
end
|
55
63
|
|
56
|
-
def handle_success(params)
|
57
|
-
end
|
58
|
-
|
59
64
|
def handle_pending(message)
|
60
65
|
raise Pending, message || "TODO"
|
61
66
|
end
|
@@ -70,42 +75,25 @@ module Cucumber
|
|
70
75
|
end
|
71
76
|
@connection.diff_ok
|
72
77
|
end
|
73
|
-
|
74
|
-
|
75
|
-
handle_fail(params)
|
76
|
-
end
|
78
|
+
|
79
|
+
alias :handle_step_failed :handle_fail
|
77
80
|
end
|
78
81
|
|
79
82
|
class DiffFailed < RequestHandler
|
80
|
-
|
81
|
-
end
|
82
|
-
|
83
|
-
def handle_step_failed(params)
|
84
|
-
handle_fail(params)
|
85
|
-
end
|
83
|
+
alias :handle_step_failed :handle_fail
|
86
84
|
end
|
87
85
|
|
88
86
|
class DiffOk < RequestHandler
|
89
|
-
|
90
|
-
end
|
91
|
-
|
92
|
-
def handle_step_failed(params)
|
93
|
-
handle_fail(params)
|
94
|
-
end
|
87
|
+
alias :handle_step_failed :handle_fail
|
95
88
|
end
|
96
89
|
|
97
90
|
class BeginScenario < RequestHandler
|
98
91
|
def execute(scenario)
|
99
92
|
super(nil) # not passing the scenario yet
|
100
93
|
end
|
101
|
-
|
102
|
-
def handle_success(params)
|
103
|
-
end
|
104
94
|
end
|
105
95
|
|
106
96
|
class EndScenario < RequestHandler
|
107
|
-
def handle_success(params)
|
108
|
-
end
|
109
97
|
end
|
110
98
|
end
|
111
99
|
end
|
@@ -4,19 +4,33 @@ require 'cucumber/wire_support/wire_language'
|
|
4
4
|
module Cucumber
|
5
5
|
module WireSupport
|
6
6
|
describe WirePacket do
|
7
|
-
|
8
|
-
|
9
|
-
|
7
|
+
|
8
|
+
describe "#to_json" do
|
9
|
+
it "should convert params to a JSON hash" do
|
10
|
+
packet = WirePacket.new('test_message', :foo => :bar)
|
11
|
+
packet.to_json.should == "[\"test_message\",{\"foo\":\"bar\"}]"
|
12
|
+
end
|
13
|
+
|
14
|
+
it "should not pass blank params" do
|
15
|
+
packet = WirePacket.new('test_message')
|
16
|
+
packet.to_json.should == "[\"test_message\"]"
|
17
|
+
end
|
10
18
|
end
|
11
19
|
|
12
20
|
describe ".parse" do
|
13
|
-
it "should understand a raw packet containing
|
21
|
+
it "should understand a raw packet containing null parameters" do
|
14
22
|
packet = WirePacket.parse("[\"test_message\",null]")
|
15
23
|
packet.message.should == 'test_message'
|
16
24
|
packet.params.should be_nil
|
17
25
|
end
|
26
|
+
|
27
|
+
it "should understand a raw packet containing no parameters" do
|
28
|
+
packet = WirePacket.parse("[\"test_message\"]")
|
29
|
+
packet.message.should == 'test_message'
|
30
|
+
packet.params.should be_nil
|
31
|
+
end
|
18
32
|
|
19
|
-
it "should understand a raw packet containging
|
33
|
+
it "should understand a raw packet containging parameters data" do
|
20
34
|
packet = WirePacket.parse("[\"test_message\",{\"foo\":\"bar\"}]")
|
21
35
|
packet.params['foo'].should == 'bar'
|
22
36
|
end
|
metadata
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: cucumber
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.5.
|
4
|
+
version: 0.5.3
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- "Aslak Helles\xC3\xB8y"
|
@@ -650,7 +650,7 @@ post_install_message: |+
|
|
650
650
|
|
651
651
|
(::) U P G R A D I N G (::)
|
652
652
|
|
653
|
-
Thank you for installing cucumber-0.5.
|
653
|
+
Thank you for installing cucumber-0.5.3.
|
654
654
|
Please be sure to read http://wiki.github.com/aslakhellesoy/cucumber/upgrading
|
655
655
|
for important information about this release. Happy cuking!
|
656
656
|
|