cucumber 0.5.2 → 0.5.3
Sign up to get free protection for your applications and to get access to all the features.
- 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
|
|