vanessa-behavior 0.4.4 → 0.4.5
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/Gemfile +3 -0
- data/bin/vanessa-behavior +17 -0
- data/features/step_definitions/wire_protocol.epf +0 -0
- data/features/wire_protocol.feature +337 -337
- data/gen/allure-results/066a48f03094fb47d11af812dafad262972166ef92cc17beec69b0403d15e56e-attachment.txt +4 -0
- data/gen/allure-results/1175036867d7ec0cc1c4721b086efed1c733561cc855645a4bb1691d12e2af8a-attachment.txt +4 -0
- data/gen/allure-results/119e1400-b255-0132-81c9-4685087c5b91-testsuite.xml +681 -0
- data/gen/allure-results/162d4bb8ec372d8eefb71b013eefb970c90c89af9680398435d530e02619b79d-attachment.txt +6 -0
- data/gen/allure-results/18260eee6a8d1a04f2bd05af817d69a1aa11727fe55bee57db0c60e1c3c63ce1-attachment.txt +3 -0
- data/gen/allure-results/2bd8007cc25428542eed58e0824a2ea58cac92c82be7c2ced51d58de9341de44-attachment.txt +6 -0
- data/gen/allure-results/33fa92f4ace8b036f4cb23f55951a9e2ccc1a84a13a23752f37cdba0b084ccce-attachment.txt +3 -0
- data/gen/allure-results/3b45e6fe443ca0ac819a8191e40c35aa68b0ca575b73c22f09be467a84929d3c-attachment.txt +4 -0
- data/gen/allure-results/3d05b2fded04a28658d4ced3a765cf6b7aa7ff1e7c8109d1a7452e33f54e8217-attachment.txt +6 -0
- data/gen/allure-results/3dab9859205b08745d11a9626734f3535200cee7709c167cd5c5a4cbfeccdd52-attachment.txt +6 -0
- data/gen/allure-results/41317e6d76d65cfc240c910c563cd44eb79690edf22bed6b4f310c7e507158cb-attachment.txt +6 -0
- data/gen/allure-results/456fab6abab3b6355e66e536be494df9848625e79e2e29c0e03556beb6e05e05-attachment.txt +6 -0
- data/gen/allure-results/4a5fe51ad867e1bf25b3703352f8c3bcf6a333e047d1e18f6a39b5ed46ed4cf3-attachment.txt +6 -0
- data/gen/allure-results/58f83a6d55fdb23000d32e42fd7b7411a571028b9496dd735193f43b44e5039e-attachment.txt +3 -0
- data/gen/allure-results/63b9d423c3dc6159f677415ee88989124738735c73e571be76fbaefae30dfff7-attachment.txt +12 -0
- data/gen/allure-results/69a76cee1d262331be437e1cba234ee9e5aee0f32d5c6b5b82319ae6280ef15e-attachment.txt +6 -0
- data/gen/allure-results/82888830a0b622d16a9bd40fe77b23d38079982d73a6517bdea731579fd0097b-attachment.txt +6 -0
- data/gen/allure-results/8824d2672f43c8557b8ef8b1c39dbeacd8ff7ab3bec9f66ef603b90825d10cce-attachment.txt +4 -0
- data/gen/allure-results/926407373bf5fedbe4ba78b1a25053f2dbe90c16e69ed79a3b00546a4cadcb52-attachment.txt +9 -0
- data/gen/allure-results/bf9b0c088d112b524b14a8235357c626b2bc8479fba40952c6a8f71c4d3a86d7-attachment.txt +7 -0
- data/gen/allure-results/dd8232f6b529d8be2eef646edd2409cd793b32571dd5af1760a88fcfc8bee738-attachment.txt +2 -0
- data/gen/allure-results/de76a3eff37fd81f34b0c5106b38ecda07f13bedae1f294d2bc891379df5e3de-attachment.txt +3 -0
- data/gen/allure-results/f9694897400de0589828da7b44c550fc7bd9df04e6050cb2fcf9ac184fe25292-attachment.txt +1 -0
- metadata +29 -6
- data/bin/keep.me +0 -0
- data/bin/vanessa-behavior.exe +0 -0
- data/lib/TemplateEpf/Temp/ObjectModule_wire_protocol.txt +0 -0
|
@@ -1,337 +1,337 @@
|
|
|
1
|
-
@[ИмяФичи]=wire_protocol;\features
|
|
2
|
-
|
|
3
|
-
|
|
4
|
-
Feature: Wire Protocol
|
|
5
|
-
In order to be allow Cucumber to touch my app in intimate places
|
|
6
|
-
As a developer on platform which doesn't support Ruby
|
|
7
|
-
I want a low-level protocol which Cucumber can use to run steps within my app
|
|
8
|
-
|
|
9
|
-
#
|
|
10
|
-
# Cucumber's wire protocol is an implementation of Cucumber's internal
|
|
11
|
-
# 'programming language' abstraction, and allows step definitions to be
|
|
12
|
-
# implemented and invoked on any platform.
|
|
13
|
-
#
|
|
14
|
-
# Communication is over a TCP socket, which Cucumber connects to when it finds
|
|
15
|
-
# a definition file with the .wire extension in the step_definitions folder
|
|
16
|
-
# (or other load path). Note that these files are rendered with ERB when loaded.
|
|
17
|
-
#
|
|
18
|
-
# Cucumber sends the following request messages out over the wire:
|
|
19
|
-
#
|
|
20
|
-
# * step_matches : this is used to find out whether the wire server has a
|
|
21
|
-
# definition for a given step
|
|
22
|
-
# * invoke : this is used to ask for a step definition to be invoked
|
|
23
|
-
# * begin_scenario : signals that cucumber is about to execute a scenario
|
|
24
|
-
# * end_scenario : signals that cucumber has finished executing a scenario
|
|
25
|
-
# * snippet_text : requests a snippet for an undefined step
|
|
26
|
-
#
|
|
27
|
-
# Every message supports two standard responses:
|
|
28
|
-
# * success : which expects different arguments (sometimes none at
|
|
29
|
-
# all) depending on the request.
|
|
30
|
-
# * fail : causes a Cucumber::WireSupport::WireException to be
|
|
31
|
-
# raised.
|
|
32
|
-
#
|
|
33
|
-
# Some messages support more responses - see below for details.
|
|
34
|
-
#
|
|
35
|
-
# A WirePacket flowing in either direction is formatted as a JSON-encoded
|
|
36
|
-
# string, with a newline character signaling the end of a packet. See the
|
|
37
|
-
# specs for Cucumber::WireSupport::WirePacket for more details.
|
|
38
|
-
#
|
|
39
|
-
# These messages are described in detail below, with examples.
|
|
40
|
-
#
|
|
41
|
-
|
|
42
|
-
Background:
|
|
43
|
-
Given a file named 'features/wired.feature' with:
|
|
44
|
-
"""
|
|
45
|
-
Feature: High strung
|
|
46
|
-
Scenario: Wired
|
|
47
|
-
Given we're all wired
|
|
48
|
-
|
|
49
|
-
"""
|
|
50
|
-
And a file named 'features/step_definitions/some_remote_place.wire' with:
|
|
51
|
-
"""
|
|
52
|
-
host: localhost
|
|
53
|
-
port: 54321
|
|
54
|
-
|
|
55
|
-
"""
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
#
|
|
59
|
-
# # Request: 'step_matches'
|
|
60
|
-
#
|
|
61
|
-
# When the features have been parsed, Cucumber will send a step_matches
|
|
62
|
-
# message to ask the wire server if it can match a step name. This happens for
|
|
63
|
-
# each of the steps in each of the features.
|
|
64
|
-
#
|
|
65
|
-
# The wire server replies with an array of StepMatch objects.
|
|
66
|
-
|
|
67
|
-
Scenario: Dry run finds no step match
|
|
68
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
69
|
-
| request | response |
|
|
70
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
|
71
|
-
When I run 'cucumber --dry-run --no-snippets -f progress'
|
|
72
|
-
And it should pass with:
|
|
73
|
-
"""
|
|
74
|
-
U
|
|
75
|
-
|
|
76
|
-
1 scenario (1 undefined)
|
|
77
|
-
1 step (1 undefined)
|
|
78
|
-
|
|
79
|
-
"""
|
|
80
|
-
|
|
81
|
-
# When each StepMatch is returned, it contains the following data:
|
|
82
|
-
# * id - identifier for the step definition to be used later when if it
|
|
83
|
-
# needs to be invoked. The identifier can be any string value and
|
|
84
|
-
# is simply used for the wire server's own reference.
|
|
85
|
-
# * args - any argument values as captured by the wire end's own regular
|
|
86
|
-
# expression (or other argument matching) process.
|
|
87
|
-
Scenario: Dry run finds a step match
|
|
88
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
89
|
-
| request | response |
|
|
90
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
91
|
-
When I run 'cucumber --dry-run -f progress'
|
|
92
|
-
And it should pass with:
|
|
93
|
-
"""
|
|
94
|
-
-
|
|
95
|
-
|
|
96
|
-
1 scenario (1 skipped)
|
|
97
|
-
1 step (1 skipped)
|
|
98
|
-
|
|
99
|
-
"""
|
|
100
|
-
|
|
101
|
-
# Optionally, the StepMatch can also contain a source reference, and a native
|
|
102
|
-
# regexp string which will be used by some formatters.
|
|
103
|
-
Scenario: Step matches returns details about the remote step definition
|
|
104
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
105
|
-
| request | response |
|
|
106
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
|
|
107
|
-
When I run 'cucumber -f stepdefs --dry-run'
|
|
108
|
-
Then it should pass with:
|
|
109
|
-
"""
|
|
110
|
-
-
|
|
111
|
-
|
|
112
|
-
we.* # MyApp.MyClass:123
|
|
113
|
-
|
|
114
|
-
1 scenario (1 skipped)
|
|
115
|
-
1 step (1 skipped)
|
|
116
|
-
|
|
117
|
-
"""
|
|
118
|
-
And the stderr should not contain anything
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
#
|
|
122
|
-
# # Request: 'invoke'
|
|
123
|
-
#
|
|
124
|
-
# Assuming a StepMatch was returned for a given step name, when it's time to
|
|
125
|
-
# invoke that step definition, Cucumber will send an invoke message.
|
|
126
|
-
#
|
|
127
|
-
# The invoke message contains the ID of the step definition, as returned by
|
|
128
|
-
# the wire server in response to the the step_matches call, along with the
|
|
129
|
-
# arguments that were parsed from the step name during the same step_matches
|
|
130
|
-
# call.
|
|
131
|
-
#
|
|
132
|
-
# The wire server will normally[1] reply one of the following:
|
|
133
|
-
# * success
|
|
134
|
-
# * fail
|
|
135
|
-
# * pending : optionally takes a message argument
|
|
136
|
-
#
|
|
137
|
-
# [1] This isn't the whole story: see also wire_protocol_table_diffing.feature
|
|
138
|
-
#
|
|
139
|
-
|
|
140
|
-
# ## Pending Steps
|
|
141
|
-
#
|
|
142
|
-
Scenario: Invoke a step definition which is pending
|
|
143
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
144
|
-
| request | response |
|
|
145
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
146
|
-
| ["begin_scenario"] | ["success"] |
|
|
147
|
-
| ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"] |
|
|
148
|
-
| ["end_scenario"] | ["success"] |
|
|
149
|
-
When I run 'cucumber -f pretty -q'
|
|
150
|
-
And it should pass with:
|
|
151
|
-
"""
|
|
152
|
-
Feature: High strung
|
|
153
|
-
|
|
154
|
-
Scenario: Wired
|
|
155
|
-
Given we're all wired
|
|
156
|
-
I'll do it later (Cucumber::Pending)
|
|
157
|
-
features/wired.feature:3:in 'Given we're all wired'
|
|
158
|
-
|
|
159
|
-
1 scenario (1 pending)
|
|
160
|
-
1 step (1 pending)
|
|
161
|
-
|
|
162
|
-
"""
|
|
163
|
-
|
|
164
|
-
# ## Passing Steps
|
|
165
|
-
#
|
|
166
|
-
Scenario: Invoke a step definition which passes
|
|
167
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
168
|
-
| request | response |
|
|
169
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
170
|
-
| ["begin_scenario"] | ["success"] |
|
|
171
|
-
| ["invoke",{"id":"1","args":[]}] | ["success"] |
|
|
172
|
-
| ["end_scenario"] | ["success"] |
|
|
173
|
-
When I run 'cucumber -f progress'
|
|
174
|
-
And it should pass with:
|
|
175
|
-
"""
|
|
176
|
-
.
|
|
177
|
-
|
|
178
|
-
1 scenario (1 passed)
|
|
179
|
-
1 step (1 passed)
|
|
180
|
-
|
|
181
|
-
"""
|
|
182
|
-
|
|
183
|
-
# ## Failing Steps
|
|
184
|
-
#
|
|
185
|
-
# When an invoked step definition fails, it can return details of the exception
|
|
186
|
-
# in the reply to invoke. This causes a Cucumber::WireSupport::WireException to be
|
|
187
|
-
# raised.
|
|
188
|
-
#
|
|
189
|
-
# Valid arguments are:
|
|
190
|
-
# * message (mandatory)
|
|
191
|
-
# * exception
|
|
192
|
-
# * backtrace
|
|
193
|
-
#
|
|
194
|
-
# See the specs for Cucumber::WireSupport::WireException for more details
|
|
195
|
-
#
|
|
196
|
-
Scenario: Invoke a step definition which fails
|
|
197
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
198
|
-
| request | response |
|
|
199
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
200
|
-
| ["begin_scenario"] | ["success"] |
|
|
201
|
-
| ["invoke",{"id":"1","args":[]}] | ["fail",{"message":"The wires are down", "exception":"Some.Foreign.ExceptionType"}] |
|
|
202
|
-
| ["end_scenario"] | ["success"] |
|
|
203
|
-
When I run 'cucumber -f progress'
|
|
204
|
-
Then the stderr should not contain anything
|
|
205
|
-
And it should fail with:
|
|
206
|
-
"""
|
|
207
|
-
F
|
|
208
|
-
|
|
209
|
-
(::) failed steps (::)
|
|
210
|
-
|
|
211
|
-
The wires are down (Some.Foreign.ExceptionType from localhost:54321)
|
|
212
|
-
features/wired.feature:3:in 'Given we're all wired'
|
|
213
|
-
|
|
214
|
-
Failing Scenarios:
|
|
215
|
-
cucumber features/wired.feature:2 # Scenario: Wired
|
|
216
|
-
|
|
217
|
-
1 scenario (1 failed)
|
|
218
|
-
1 step (1 failed)
|
|
219
|
-
|
|
220
|
-
"""
|
|
221
|
-
|
|
222
|
-
# ## Step Arguments
|
|
223
|
-
#
|
|
224
|
-
# Imagine we have a step definition like:
|
|
225
|
-
#
|
|
226
|
-
# Given /we're all (.*)/ do | what_we_are |
|
|
227
|
-
# end
|
|
228
|
-
#
|
|
229
|
-
# When this step definition matches the step name in our feature, the word
|
|
230
|
-
# 'wired' will be captured as an argument.
|
|
231
|
-
#
|
|
232
|
-
# Cucumber expects this StepArgument to be returned in the StepMatch. The keys
|
|
233
|
-
# have the following meanings:
|
|
234
|
-
# * val : the value of the string captured for that argument from the step
|
|
235
|
-
# name passed in step_matches
|
|
236
|
-
# * pos : the position within the step name that the argument was matched
|
|
237
|
-
# (used for formatter highlighting)
|
|
238
|
-
#
|
|
239
|
-
Scenario: Invoke a step definition which takes string arguments (and passes)
|
|
240
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
241
|
-
| request | response |
|
|
242
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
|
|
243
|
-
| ["begin_scenario"] | ["success"] |
|
|
244
|
-
| ["invoke",{"id":"1","args":["wired"]}] | ["success"] |
|
|
245
|
-
| ["end_scenario"] | ["success"] |
|
|
246
|
-
When I run 'cucumber -f progress'
|
|
247
|
-
Then the stderr should not contain anything
|
|
248
|
-
And it should pass with:
|
|
249
|
-
"""
|
|
250
|
-
.
|
|
251
|
-
|
|
252
|
-
1 scenario (1 passed)
|
|
253
|
-
1 step (1 passed)
|
|
254
|
-
|
|
255
|
-
"""
|
|
256
|
-
|
|
257
|
-
# ## Multiline Table Arguments
|
|
258
|
-
#
|
|
259
|
-
# When the step has a multiline table argument, it will be passed with the
|
|
260
|
-
# invoke message as a string - a serialized JSON array of array of strings.
|
|
261
|
-
# In the following scenario our step definition takes two arguments - one
|
|
262
|
-
# captures the "we're" and the other takes the table.
|
|
263
|
-
Scenario: Invoke a step definition which takes table arguments (and passes)
|
|
264
|
-
Given a file named 'features/wired_on_tables.feature' with:
|
|
265
|
-
"""
|
|
266
|
-
Feature: High strung
|
|
267
|
-
Scenario: Wired and more
|
|
268
|
-
Given we're all:
|
|
269
|
-
| wired |
|
|
270
|
-
| high |
|
|
271
|
-
| happy |
|
|
272
|
-
"""
|
|
273
|
-
And there is a wire server running on port 54321 which understands the following protocol:
|
|
274
|
-
| request | response |
|
|
275
|
-
| ["step_matches",{"name_to_match":"we're all:"}] | ["success",[{"id":"1", "args":[{"val":"we're", "pos":0}]}]] |
|
|
276
|
-
| ["begin_scenario"] | ["success"] |
|
|
277
|
-
| ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success"] |
|
|
278
|
-
| ["end_scenario"] | ["success"] |
|
|
279
|
-
When I run 'cucumber -f progress features/wired_on_tables.feature'
|
|
280
|
-
Then the stderr should not contain anything
|
|
281
|
-
And it should pass with:
|
|
282
|
-
"""
|
|
283
|
-
.
|
|
284
|
-
|
|
285
|
-
1 scenario (1 passed)
|
|
286
|
-
1 step (1 passed)
|
|
287
|
-
|
|
288
|
-
"""
|
|
289
|
-
|
|
290
|
-
|
|
291
|
-
#
|
|
292
|
-
# # Request: 'snippets'
|
|
293
|
-
#
|
|
294
|
-
Scenario: Wire server returns snippets for a step that didn't match
|
|
295
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
296
|
-
| request | response |
|
|
297
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
|
298
|
-
| ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["success","foo()\n bar;\nbaz"] |
|
|
299
|
-
| ["begin_scenario"] | ["success"] |
|
|
300
|
-
| ["end_scenario"] | ["success"] |
|
|
301
|
-
When I run 'cucumber -f pretty'
|
|
302
|
-
Then the stderr should not contain anything
|
|
303
|
-
And it should pass with:
|
|
304
|
-
"""
|
|
305
|
-
Feature: High strung
|
|
306
|
-
|
|
307
|
-
Scenario: Wired # features/wired.feature:2
|
|
308
|
-
Given we're all wired # features/wired.feature:3
|
|
309
|
-
|
|
310
|
-
1 scenario (1 undefined)
|
|
311
|
-
1 step (1 undefined)
|
|
312
|
-
"""
|
|
313
|
-
And the output should contain:
|
|
314
|
-
"""
|
|
315
|
-
|
|
316
|
-
You can implement step definitions for undefined steps with these snippets:
|
|
317
|
-
|
|
318
|
-
foo()
|
|
319
|
-
bar;
|
|
320
|
-
baz
|
|
321
|
-
|
|
322
|
-
"""
|
|
323
|
-
|
|
324
|
-
#
|
|
325
|
-
# # Bad Response
|
|
326
|
-
#
|
|
327
|
-
Scenario: Unexpected response
|
|
328
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
329
|
-
| request | response |
|
|
330
|
-
| ["begin_scenario"] | ["yikes"] |
|
|
331
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
332
|
-
When I run 'cucumber -f pretty'
|
|
333
|
-
Then the stdout should contain:
|
|
334
|
-
"""
|
|
335
|
-
undefined method 'handle_yikes'
|
|
336
|
-
"""
|
|
337
|
-
|
|
1
|
+
@[ИмяФичи]=wire_protocol;\features
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
Feature: Wire Protocol
|
|
5
|
+
In order to be allow Cucumber to touch my app in intimate places
|
|
6
|
+
As a developer on platform which doesn't support Ruby
|
|
7
|
+
I want a low-level protocol which Cucumber can use to run steps within my app
|
|
8
|
+
|
|
9
|
+
#
|
|
10
|
+
# Cucumber's wire protocol is an implementation of Cucumber's internal
|
|
11
|
+
# 'programming language' abstraction, and allows step definitions to be
|
|
12
|
+
# implemented and invoked on any platform.
|
|
13
|
+
#
|
|
14
|
+
# Communication is over a TCP socket, which Cucumber connects to when it finds
|
|
15
|
+
# a definition file with the .wire extension in the step_definitions folder
|
|
16
|
+
# (or other load path). Note that these files are rendered with ERB when loaded.
|
|
17
|
+
#
|
|
18
|
+
# Cucumber sends the following request messages out over the wire:
|
|
19
|
+
#
|
|
20
|
+
# * step_matches : this is used to find out whether the wire server has a
|
|
21
|
+
# definition for a given step
|
|
22
|
+
# * invoke : this is used to ask for a step definition to be invoked
|
|
23
|
+
# * begin_scenario : signals that cucumber is about to execute a scenario
|
|
24
|
+
# * end_scenario : signals that cucumber has finished executing a scenario
|
|
25
|
+
# * snippet_text : requests a snippet for an undefined step
|
|
26
|
+
#
|
|
27
|
+
# Every message supports two standard responses:
|
|
28
|
+
# * success : which expects different arguments (sometimes none at
|
|
29
|
+
# all) depending on the request.
|
|
30
|
+
# * fail : causes a Cucumber::WireSupport::WireException to be
|
|
31
|
+
# raised.
|
|
32
|
+
#
|
|
33
|
+
# Some messages support more responses - see below for details.
|
|
34
|
+
#
|
|
35
|
+
# A WirePacket flowing in either direction is formatted as a JSON-encoded
|
|
36
|
+
# string, with a newline character signaling the end of a packet. See the
|
|
37
|
+
# specs for Cucumber::WireSupport::WirePacket for more details.
|
|
38
|
+
#
|
|
39
|
+
# These messages are described in detail below, with examples.
|
|
40
|
+
#
|
|
41
|
+
|
|
42
|
+
Background:
|
|
43
|
+
Given a file named 'features/wired.feature' with:
|
|
44
|
+
"""
|
|
45
|
+
Feature: High strung
|
|
46
|
+
Scenario: Wired
|
|
47
|
+
Given we're all wired
|
|
48
|
+
|
|
49
|
+
"""
|
|
50
|
+
And a file named 'features/step_definitions/some_remote_place.wire' with:
|
|
51
|
+
"""
|
|
52
|
+
host: localhost
|
|
53
|
+
port: 54321
|
|
54
|
+
|
|
55
|
+
"""
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
#
|
|
59
|
+
# # Request: 'step_matches'
|
|
60
|
+
#
|
|
61
|
+
# When the features have been parsed, Cucumber will send a step_matches
|
|
62
|
+
# message to ask the wire server if it can match a step name. This happens for
|
|
63
|
+
# each of the steps in each of the features.
|
|
64
|
+
#
|
|
65
|
+
# The wire server replies with an array of StepMatch objects.
|
|
66
|
+
|
|
67
|
+
Scenario: Dry run finds no step match
|
|
68
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
69
|
+
| request | response |
|
|
70
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
|
71
|
+
When I run 'cucumber --dry-run --no-snippets -f progress'
|
|
72
|
+
And it should pass with:
|
|
73
|
+
"""
|
|
74
|
+
U
|
|
75
|
+
|
|
76
|
+
1 scenario (1 undefined)
|
|
77
|
+
1 step (1 undefined)
|
|
78
|
+
|
|
79
|
+
"""
|
|
80
|
+
|
|
81
|
+
# When each StepMatch is returned, it contains the following data:
|
|
82
|
+
# * id - identifier for the step definition to be used later when if it
|
|
83
|
+
# needs to be invoked. The identifier can be any string value and
|
|
84
|
+
# is simply used for the wire server's own reference.
|
|
85
|
+
# * args - any argument values as captured by the wire end's own regular
|
|
86
|
+
# expression (or other argument matching) process.
|
|
87
|
+
Scenario: Dry run finds a step match
|
|
88
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
89
|
+
| request | response |
|
|
90
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
91
|
+
When I run 'cucumber --dry-run -f progress'
|
|
92
|
+
And it should pass with:
|
|
93
|
+
"""
|
|
94
|
+
-
|
|
95
|
+
|
|
96
|
+
1 scenario (1 skipped)
|
|
97
|
+
1 step (1 skipped)
|
|
98
|
+
|
|
99
|
+
"""
|
|
100
|
+
|
|
101
|
+
# Optionally, the StepMatch can also contain a source reference, and a native
|
|
102
|
+
# regexp string which will be used by some formatters.
|
|
103
|
+
Scenario: Step matches returns details about the remote step definition
|
|
104
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
105
|
+
| request | response |
|
|
106
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
|
|
107
|
+
When I run 'cucumber -f stepdefs --dry-run'
|
|
108
|
+
Then it should pass with:
|
|
109
|
+
"""
|
|
110
|
+
-
|
|
111
|
+
|
|
112
|
+
we.* # MyApp.MyClass:123
|
|
113
|
+
|
|
114
|
+
1 scenario (1 skipped)
|
|
115
|
+
1 step (1 skipped)
|
|
116
|
+
|
|
117
|
+
"""
|
|
118
|
+
And the stderr should not contain anything
|
|
119
|
+
|
|
120
|
+
|
|
121
|
+
#
|
|
122
|
+
# # Request: 'invoke'
|
|
123
|
+
#
|
|
124
|
+
# Assuming a StepMatch was returned for a given step name, when it's time to
|
|
125
|
+
# invoke that step definition, Cucumber will send an invoke message.
|
|
126
|
+
#
|
|
127
|
+
# The invoke message contains the ID of the step definition, as returned by
|
|
128
|
+
# the wire server in response to the the step_matches call, along with the
|
|
129
|
+
# arguments that were parsed from the step name during the same step_matches
|
|
130
|
+
# call.
|
|
131
|
+
#
|
|
132
|
+
# The wire server will normally[1] reply one of the following:
|
|
133
|
+
# * success
|
|
134
|
+
# * fail
|
|
135
|
+
# * pending : optionally takes a message argument
|
|
136
|
+
#
|
|
137
|
+
# [1] This isn't the whole story: see also wire_protocol_table_diffing.feature
|
|
138
|
+
#
|
|
139
|
+
|
|
140
|
+
# ## Pending Steps
|
|
141
|
+
#
|
|
142
|
+
Scenario: Invoke a step definition which is pending
|
|
143
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
144
|
+
| request | response |
|
|
145
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
146
|
+
| ["begin_scenario"] | ["success"] |
|
|
147
|
+
| ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"] |
|
|
148
|
+
| ["end_scenario"] | ["success"] |
|
|
149
|
+
When I run 'cucumber -f pretty -q'
|
|
150
|
+
And it should pass with:
|
|
151
|
+
"""
|
|
152
|
+
Feature: High strung
|
|
153
|
+
|
|
154
|
+
Scenario: Wired
|
|
155
|
+
Given we're all wired
|
|
156
|
+
I'll do it later (Cucumber::Pending)
|
|
157
|
+
features/wired.feature:3:in 'Given we're all wired'
|
|
158
|
+
|
|
159
|
+
1 scenario (1 pending)
|
|
160
|
+
1 step (1 pending)
|
|
161
|
+
|
|
162
|
+
"""
|
|
163
|
+
|
|
164
|
+
# ## Passing Steps
|
|
165
|
+
#
|
|
166
|
+
Scenario: Invoke a step definition which passes
|
|
167
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
168
|
+
| request | response |
|
|
169
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
170
|
+
| ["begin_scenario"] | ["success"] |
|
|
171
|
+
| ["invoke",{"id":"1","args":[]}] | ["success"] |
|
|
172
|
+
| ["end_scenario"] | ["success"] |
|
|
173
|
+
When I run 'cucumber -f progress'
|
|
174
|
+
And it should pass with:
|
|
175
|
+
"""
|
|
176
|
+
.
|
|
177
|
+
|
|
178
|
+
1 scenario (1 passed)
|
|
179
|
+
1 step (1 passed)
|
|
180
|
+
|
|
181
|
+
"""
|
|
182
|
+
|
|
183
|
+
# ## Failing Steps
|
|
184
|
+
#
|
|
185
|
+
# When an invoked step definition fails, it can return details of the exception
|
|
186
|
+
# in the reply to invoke. This causes a Cucumber::WireSupport::WireException to be
|
|
187
|
+
# raised.
|
|
188
|
+
#
|
|
189
|
+
# Valid arguments are:
|
|
190
|
+
# * message (mandatory)
|
|
191
|
+
# * exception
|
|
192
|
+
# * backtrace
|
|
193
|
+
#
|
|
194
|
+
# See the specs for Cucumber::WireSupport::WireException for more details
|
|
195
|
+
#
|
|
196
|
+
Scenario: Invoke a step definition which fails
|
|
197
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
198
|
+
| request | response |
|
|
199
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
200
|
+
| ["begin_scenario"] | ["success"] |
|
|
201
|
+
| ["invoke",{"id":"1","args":[]}] | ["fail",{"message":"The wires are down", "exception":"Some.Foreign.ExceptionType"}] |
|
|
202
|
+
| ["end_scenario"] | ["success"] |
|
|
203
|
+
When I run 'cucumber -f progress'
|
|
204
|
+
Then the stderr should not contain anything
|
|
205
|
+
And it should fail with:
|
|
206
|
+
"""
|
|
207
|
+
F
|
|
208
|
+
|
|
209
|
+
(::) failed steps (::)
|
|
210
|
+
|
|
211
|
+
The wires are down (Some.Foreign.ExceptionType from localhost:54321)
|
|
212
|
+
features/wired.feature:3:in 'Given we're all wired'
|
|
213
|
+
|
|
214
|
+
Failing Scenarios:
|
|
215
|
+
cucumber features/wired.feature:2 # Scenario: Wired
|
|
216
|
+
|
|
217
|
+
1 scenario (1 failed)
|
|
218
|
+
1 step (1 failed)
|
|
219
|
+
|
|
220
|
+
"""
|
|
221
|
+
|
|
222
|
+
# ## Step Arguments
|
|
223
|
+
#
|
|
224
|
+
# Imagine we have a step definition like:
|
|
225
|
+
#
|
|
226
|
+
# Given /we're all (.*)/ do | what_we_are |
|
|
227
|
+
# end
|
|
228
|
+
#
|
|
229
|
+
# When this step definition matches the step name in our feature, the word
|
|
230
|
+
# 'wired' will be captured as an argument.
|
|
231
|
+
#
|
|
232
|
+
# Cucumber expects this StepArgument to be returned in the StepMatch. The keys
|
|
233
|
+
# have the following meanings:
|
|
234
|
+
# * val : the value of the string captured for that argument from the step
|
|
235
|
+
# name passed in step_matches
|
|
236
|
+
# * pos : the position within the step name that the argument was matched
|
|
237
|
+
# (used for formatter highlighting)
|
|
238
|
+
#
|
|
239
|
+
Scenario: Invoke a step definition which takes string arguments (and passes)
|
|
240
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
241
|
+
| request | response |
|
|
242
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
|
|
243
|
+
| ["begin_scenario"] | ["success"] |
|
|
244
|
+
| ["invoke",{"id":"1","args":["wired"]}] | ["success"] |
|
|
245
|
+
| ["end_scenario"] | ["success"] |
|
|
246
|
+
When I run 'cucumber -f progress'
|
|
247
|
+
Then the stderr should not contain anything
|
|
248
|
+
And it should pass with:
|
|
249
|
+
"""
|
|
250
|
+
.
|
|
251
|
+
|
|
252
|
+
1 scenario (1 passed)
|
|
253
|
+
1 step (1 passed)
|
|
254
|
+
|
|
255
|
+
"""
|
|
256
|
+
|
|
257
|
+
# ## Multiline Table Arguments
|
|
258
|
+
#
|
|
259
|
+
# When the step has a multiline table argument, it will be passed with the
|
|
260
|
+
# invoke message as a string - a serialized JSON array of array of strings.
|
|
261
|
+
# In the following scenario our step definition takes two arguments - one
|
|
262
|
+
# captures the "we're" and the other takes the table.
|
|
263
|
+
Scenario: Invoke a step definition which takes table arguments (and passes)
|
|
264
|
+
Given a file named 'features/wired_on_tables.feature' with:
|
|
265
|
+
"""
|
|
266
|
+
Feature: High strung
|
|
267
|
+
Scenario: Wired and more
|
|
268
|
+
Given we're all:
|
|
269
|
+
| wired |
|
|
270
|
+
| high |
|
|
271
|
+
| happy |
|
|
272
|
+
"""
|
|
273
|
+
And there is a wire server running on port 54321 which understands the following protocol:
|
|
274
|
+
| request | response |
|
|
275
|
+
| ["step_matches",{"name_to_match":"we're all:"}] | ["success",[{"id":"1", "args":[{"val":"we're", "pos":0}]}]] |
|
|
276
|
+
| ["begin_scenario"] | ["success"] |
|
|
277
|
+
| ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success"] |
|
|
278
|
+
| ["end_scenario"] | ["success"] |
|
|
279
|
+
When I run 'cucumber -f progress features/wired_on_tables.feature'
|
|
280
|
+
Then the stderr should not contain anything
|
|
281
|
+
And it should pass with:
|
|
282
|
+
"""
|
|
283
|
+
.
|
|
284
|
+
|
|
285
|
+
1 scenario (1 passed)
|
|
286
|
+
1 step (1 passed)
|
|
287
|
+
|
|
288
|
+
"""
|
|
289
|
+
|
|
290
|
+
|
|
291
|
+
#
|
|
292
|
+
# # Request: 'snippets'
|
|
293
|
+
#
|
|
294
|
+
Scenario: Wire server returns snippets for a step that didn't match
|
|
295
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
296
|
+
| request | response |
|
|
297
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
|
298
|
+
| ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["success","foo()\n bar;\nbaz"] |
|
|
299
|
+
| ["begin_scenario"] | ["success"] |
|
|
300
|
+
| ["end_scenario"] | ["success"] |
|
|
301
|
+
When I run 'cucumber -f pretty'
|
|
302
|
+
Then the stderr should not contain anything
|
|
303
|
+
And it should pass with:
|
|
304
|
+
"""
|
|
305
|
+
Feature: High strung
|
|
306
|
+
|
|
307
|
+
Scenario: Wired # features/wired.feature:2
|
|
308
|
+
Given we're all wired # features/wired.feature:3
|
|
309
|
+
|
|
310
|
+
1 scenario (1 undefined)
|
|
311
|
+
1 step (1 undefined)
|
|
312
|
+
"""
|
|
313
|
+
And the output should contain:
|
|
314
|
+
"""
|
|
315
|
+
|
|
316
|
+
You can implement step definitions for undefined steps with these snippets:
|
|
317
|
+
|
|
318
|
+
foo()
|
|
319
|
+
bar;
|
|
320
|
+
baz
|
|
321
|
+
|
|
322
|
+
"""
|
|
323
|
+
|
|
324
|
+
#
|
|
325
|
+
# # Bad Response
|
|
326
|
+
#
|
|
327
|
+
Scenario: Unexpected response
|
|
328
|
+
Given there is a wire server running on port 54321 which understands the following protocol:
|
|
329
|
+
| request | response |
|
|
330
|
+
| ["begin_scenario"] | ["yikes"] |
|
|
331
|
+
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
|
332
|
+
When I run 'cucumber -f pretty'
|
|
333
|
+
Then the stdout should contain:
|
|
334
|
+
"""
|
|
335
|
+
undefined method 'handle_yikes'
|
|
336
|
+
"""
|
|
337
|
+
|