1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
Feature: Invoke message
Assuming a StepMatch was returned for a given step name, when it's time to
invoke that step definition, Cucumber will send an invoke message.
The invoke message contains the ID of the step definition, as returned by
the wire server in response to the the step_matches call, along with the
arguments that were parsed from the step name during the same step_matches
call.
The wire server will normally reply one of the following:
* `success`
* `fail`
* `pending` - optionally takes a message argument
This isn't quite the whole story: see also table_diffing.feature
Background:
Given a file named "features/wired.feature" with:
"""
Feature: High strung
Scenario: Wired
Given we're all wired
"""
And a file named "features/step_definitions/some_remote_place.wire" with:
"""
host: localhost
port: 54321
"""
@spawn
Scenario: Invoke a step definition which is pending
Given there is a wire server running on port 54321 which understands the following protocol:
| request | response |
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
| ["begin_scenario"] | ["success"] |
| ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"] |
| ["end_scenario"] | ["success"] |
When I run `cucumber -f pretty -q`
And it should pass with exactly:
"""
Feature: High strung
Scenario: Wired
Given we're all wired
I'll do it later (Cucumber::Pending)
features/wired.feature:3:in `Given we're all wired'
1 scenario (1 pending)
1 step (1 pending)
"""
Scenario: Invoke a step definition which passes
Given there is a wire server running on port 54321 which understands the following protocol:
| request | response |
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
| ["begin_scenario"] | ["success"] |
| ["invoke",{"id":"1","args":[]}] | ["success"] |
| ["end_scenario"] | ["success"] |
When I run `cucumber -f progress`
And it should pass with:
"""
.
1 scenario (1 passed)
1 step (1 passed)
"""
@spawn
Scenario: Invoke a step definition which fails
If an invoked step definition fails, it can return details of the exception
in the reply to invoke. This causes a Cucumber::WireSupport::WireException to be
raised.
Valid arguments are:
- `message` (mandatory)
- `exception`
- `backtrace`
See the specs for Cucumber::WireSupport::WireException for more details
Given there is a wire server running on port 54321 which understands the following protocol:
| request | response |
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
| ["begin_scenario"] | ["success"] |
| ["invoke",{"id":"1","args":[]}] | ["fail",{"message":"The wires are down", "exception":"Some.Foreign.ExceptionType"}] |
| ["end_scenario"] | ["success"] |
When I run `cucumber -f progress`
Then the stderr should not contain anything
And it should fail with:
"""
F
(::) failed steps (::)
The wires are down (Some.Foreign.ExceptionType from localhost:54321)
features/wired.feature:3:in `Given we're all wired'
Failing Scenarios:
cucumber features/wired.feature:2 # Scenario: Wired
1 scenario (1 failed)
1 step (1 failed)
"""
Scenario: Invoke a step definition which takes string arguments (and passes)
If the step definition at the end of the wire captures arguments, these are
communicated back to Cucumber in the `step_matches` message.
Cucumber expects these StepArguments to be returned in the StepMatch. The keys
have the following meanings:
- `val` - the value of the string captured for that argument from the step
name passed in step_matches
- `pos` - the position within the step name that the argument was matched
(used for formatter highlighting)
The argument values are then sent back by Cucumber in the `invoke` message.
Given there is a wire server running on port 54321 which understands the following protocol:
| request | response |
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
| ["begin_scenario"] | ["success"] |
| ["invoke",{"id":"1","args":["wired"]}] | ["success"] |
| ["end_scenario"] | ["success"] |
When I run `cucumber -f progress`
Then the stderr should not contain anything
And it should pass with:
"""
.
1 scenario (1 passed)
1 step (1 passed)
"""
Scenario: Invoke a step definition which takes regular and table arguments (and passes)
If the step has a multiline table argument, it will be passed with the
invoke message as an array of array of strings.
In this scenario our step definition takes two arguments - one
captures the "we're" and the other takes the table.
Given a file named "features/wired_on_tables.feature" with:
"""
Feature: High strung
Scenario: Wired and more
Given we're all:
| wired |
| high |
| happy |
"""
And there is a wire server running on port 54321 which understands the following protocol:
| request | response |
| ["step_matches",{"name_to_match":"we're all:"}] | ["success",[{"id":"1", "args":[{"val":"we're", "pos":0}]}]] |
| ["begin_scenario"] | ["success"] |
| ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success"] |
| ["end_scenario"] | ["success"] |
When I run `cucumber -f progress features/wired_on_tables.feature`
Then the stderr should not contain anything
And it should pass with:
"""
.
1 scenario (1 passed)
1 step (1 passed)
"""
Scenario: Invoke a scenario outline step
Given a file named "features/wired_in_an_outline.feature" with:
"""
Feature:
Scenario Outline:
Given we're all <arg>
Examples:
| arg |
| wired |
"""
And there is a wire server running on port 54321 which understands the following protocol:
| request | response |
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
| ["begin_scenario"] | ["success"] |
| ["invoke",{"id":"1","args":[]}] | ["success"] |
| ["end_scenario"] | ["success"] |
When I run `cucumber -f progress features/wired_in_an_outline.feature`
Then the stderr should not contain anything
And it should pass with:
"""
.
1 scenario (1 passed)
1 step (1 passed)
"""
And the wire server should have received the following messages:
| step_matches |
| begin_scenario |
| invoke |
| end_scenario |
|
