cucumber 0.5.2 → 0.5.3

Sign up to get free protection for your applications and to get access to all the features.
@@ -1,3 +1,10 @@
1
+ == 0.5.3 2009-12-22
2
+
3
+ Another small release today to please a sister project. This time Cuke4Nuke.
4
+
5
+ === New Features
6
+ * Simplified wire protocol to mostly use success / fail responses (Matt Wynne)
7
+
1
8
  == 0.5.2 2009-12-22
2
9
 
3
10
  === New Features
@@ -1,4 +1,4 @@
1
1
  ---
2
- :patch: 2
2
+ :patch: 3
3
3
  :major: 0
4
4
  :minor: 5
@@ -5,7 +5,7 @@
5
5
 
6
6
  Gem::Specification.new do |s|
7
7
  s.name = %q{cucumber}
8
- s.version = "0.5.2"
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.2.
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 currently sends the following messages over the wire:
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 end has a
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
- # Message packets are formatted as JSON-encoded strings, with a newline
26
- # character signalling the end of a packet. These messages are described
27
- # below, with examples.
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 end if it can match a step name. This happens for
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 end replies with a step_match array, containing the IDs of any step
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"}] | ["step_matches",[]] |
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 a step match is returned, it contains an identifier for the step
71
- # definition to be used later when referring to this step definition again if
72
- # it needs to be invoked. The identifier can take any form (as long as it's
73
- # within a string) and is simply used for the wire end's own reference.
74
- #
75
- # The step match also contains any argument values as parsed out by the wire
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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
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 step match can also contain the a source reference, and a
92
- # native regexp string which will be used by some formatters
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"}] | ["step_matches",[{"id":"1", "args":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
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 step_match was returned for a given step name, when it's time to
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 the wire
118
- # end from the step_matches call, along with the arguments that were parsed
119
- # from the step name during the same step_matches call.
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
- # The message argument which accompanies the pending message is optional
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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
128
- | ["begin_scenario",null] | ["success", null] |
129
- | ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"] |
130
- | ["end_scenario",null] | ["success", null] |
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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
150
- | ["begin_scenario",null] | ["success",null] |
151
- | ["invoke",{"id":"1","args":[]}] | ["success",null] |
152
- | ["end_scenario",null] | ["success",null] |
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. These will then be passed by Cucumber to the formatters
165
- # for display to the user.
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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
171
- | ["begin_scenario",null] | ["success",null] |
172
- | ["invoke",{"id":"1","args":[]}] | ["step_failed",{"message":"The wires are down", "exception":"Some.Foreign.ExceptionType"}] |
173
- | ["end_scenario",null] | ["success",null] |
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 parsed as an argument.
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"}] | ["step_matches",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
212
- | ["begin_scenario",null] | ["success",null] |
213
- | ["invoke",{"id":"1","args":["wired"]}] | ["success",null] |
214
- | ["end_scenario",null] | ["success",null] |
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:"}] | ["step_matches",[{"id":"1", "args":[{"val":"we're", "pos":0}]}]] |
242
- | ["begin_scenario",null] | ["success",null] |
243
- | ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success",null] |
244
- | ["end_scenario",null] | ["success",null] |
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"}] | ["step_matches",[]] |
264
- | ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["snippet_text","foo()\n bar;\nbaz"] |
265
- | ["begin_scenario",null] | ["success",null] |
266
- | ["end_scenario",null] | ["success",null] |
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 | response |
291
- | ["begin_scenario",null] | ["yikes"] |
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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
26
- | ["begin_scenario",null] | ["success",null] |
27
- | ["invoke",{"id":"1","args":[]}] | ["diff",[[["a","b"],["c","d"]],[["x","y"],["z","z"]]]] |
28
- | ["diff_failed",null] | ["step_failed",{"message":"Not same", "exception":"DifferentException", "backtrace":["a.cs:12","b.cs:34"]}] |
29
- | ["end_scenario",null] | ["success",null] |
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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
54
- | ["begin_scenario",null] | ["success",null] |
55
- | ["invoke",{"id":"1","args":[]}] | ["diff",[[["a"],["b"]],[["a"],["b"]]]] |
56
- | ["diff_ok",null] | ["success",null] |
57
- | ["end_scenario",null] | ["success",null] |
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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
72
- | ["begin_scenario",null] | ["success",null] |
73
- | ["invoke",{"id":"1","args":[]}] | ["diff",[[["a"],["b"]],[["a"],["b"]]]] |
74
- | ["diff_ok",null] | ["step_failed",{"message":"I wanted things to be different for us"}] |
75
- | ["end_scenario",null] | ["success",null] |
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"}] | ["step_matches",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
41
- | ["begin_scenario",null] | ["success",null] |
42
- | ["invoke",{"id":"1","args":["wired"]}] | ["success",null] |
43
- | ["end_scenario",null] | ["success",null] |
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,6 +14,9 @@ module Cucumber
14
14
  raise @connection.exception(params)
15
15
  end
16
16
 
17
+ def handle_success(params)
18
+ end
19
+
17
20
  private
18
21
 
19
22
  # Props to Rails
@@ -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, @params].to_json
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 handle_step_matches(params)
15
+ def handle_success(params)
16
16
  params.map do |raw_step_match|
17
- step_definition = WireStepDefinition.new(@connection, raw_step_match)
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 handle_snippet_text(text)
43
- text
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
- def handle_step_failed(params)
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
- def handle_success(params)
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
- def handle_success(params)
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
- it "should convert to JSON" do
8
- packet = WirePacket.new('test_message', :foo => :bar)
9
- packet.to_json.should == "[\"test_message\",{\"foo\":\"bar\"}]"
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 no arguments" do
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 arguments data" do
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.2
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.2.
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