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.
@@ -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