cucumber 2.0.0.rc.4 → 2.0.0.rc.5
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.
- checksums.yaml +4 -4
- data/History.md +74 -52
- data/examples/i18n/ht/Rakefile +6 -0
- data/examples/i18n/ht/features/adisyon.feature +17 -0
- data/examples/i18n/ht/features/divizyon.feature +10 -0
- data/examples/i18n/ht/features/step_definitions/kalkilatris_steps.rb +25 -0
- data/examples/i18n/ht/lib/kalkilatris.rb +14 -0
- data/features/docs/cli/dry_run.feature +43 -0
- data/features/docs/cli/strict_mode.feature +24 -1
- data/features/docs/defining_steps/nested_steps.feature +49 -0
- data/features/docs/exception_in_after_step_hook.feature +1 -1
- data/features/docs/exception_in_around_hook.feature +80 -0
- data/features/docs/formatters/json_formatter.feature +65 -1
- data/features/docs/formatters/junit_formatter.feature +40 -0
- data/features/docs/{wire_protocol_erb.feature → wire_protocol/erb_configuration.feature} +2 -2
- data/features/docs/wire_protocol/handle_unexpected_response.feature +30 -0
- data/features/docs/wire_protocol/invoke_message.feature +216 -0
- data/features/docs/wire_protocol/readme.md +26 -0
- data/features/docs/wire_protocol/snippets_message.feature +51 -0
- data/features/docs/wire_protocol/step_matches_message.feature +81 -0
- data/features/docs/{wire_protocol_table_diffing.feature → wire_protocol/table_diffing.feature} +1 -0
- data/features/docs/{wire_protocol_tags.feature → wire_protocol/tags.feature} +1 -0
- data/features/docs/{wire_protocol_timeouts.feature → wire_protocol/timeouts.feature} +1 -0
- data/features/docs/work_in_progress.feature +1 -1
- data/features/docs/writing_support_code/around_hooks.feature +31 -0
- data/features/docs/writing_support_code/before_hook.feature +7 -3
- data/features/docs/writing_support_code/tagged_hooks.feature +44 -6
- data/features/lib/step_definitions/wire_steps.rb +18 -1
- data/features/lib/support/fake_wire_server.rb +10 -7
- data/lib/cucumber.rb +1 -3
- data/lib/cucumber/cli/options.rb +7 -0
- data/lib/cucumber/encoding.rb +5 -0
- data/lib/cucumber/errors.rb +8 -0
- data/lib/cucumber/filters/prepare_world.rb +13 -5
- data/lib/cucumber/formatter/console.rb +1 -1
- data/lib/cucumber/formatter/gherkin_formatter_adapter.rb +9 -6
- data/lib/cucumber/formatter/junit.rb +95 -0
- data/lib/cucumber/formatter/legacy_api/adapter.rb +39 -3
- data/lib/cucumber/platform.rb +1 -1
- data/lib/cucumber/project_initializer.rb +43 -0
- data/lib/cucumber/rb_support/rb_step_definition.rb +11 -2
- data/lib/cucumber/rb_support/rb_world.rb +2 -2
- data/lib/cucumber/rb_support/snippet.rb +1 -1
- data/lib/cucumber/rspec/doubles.rb +1 -1
- data/lib/cucumber/running_test_case.rb +115 -0
- data/lib/cucumber/runtime.rb +5 -1
- data/lib/cucumber/runtime/for_programming_languages.rb +2 -2
- data/lib/cucumber/runtime/support_code.rb +18 -8
- data/spec/cucumber/formatter/junit_spec.rb +212 -156
- data/spec/cucumber/formatter/legacy_api/adapter_spec.rb +89 -1
- data/spec/cucumber/formatter/pretty_spec.rb +13 -0
- data/spec/cucumber/project_initializer_spec.rb +87 -0
- data/spec/cucumber/rb_support/rb_step_definition_spec.rb +21 -3
- data/spec/cucumber/rb_support/snippet_spec.rb +6 -6
- data/spec/cucumber/running_test_case_spec.rb +83 -0
- data/spec/spec_helper.rb +1 -4
- metadata +35 -18
- data/bin/cuke +0 -60
- data/features/docs/report_called_undefined_steps.feature +0 -57
- data/features/docs/wire_protocol.feature +0 -337
- data/lib/cucumber/ast/facade.rb +0 -117
data/bin/cuke
DELETED
@@ -1,60 +0,0 @@
|
|
1
|
-
#!/usr/bin/env ruby
|
2
|
-
# encoding: UTF-8
|
3
|
-
$: << File.dirname(__FILE__) + '/../lib'
|
4
|
-
$: << File.dirname(__FILE__) + '/../../cucumber-ruby-core/lib'
|
5
|
-
|
6
|
-
require 'cucumber/platform'
|
7
|
-
|
8
|
-
module Cucumber
|
9
|
-
|
10
|
-
features_glob = ARGV[0] || 'features/**/*.feature'
|
11
|
-
feature_files = Dir[features_glob].reject { |f| f =~ /iso-8859-1/ }
|
12
|
-
puts "Running features:"
|
13
|
-
p feature_files
|
14
|
-
|
15
|
-
require 'cucumber/core'
|
16
|
-
extend Cucumber::Core
|
17
|
-
|
18
|
-
require 'cucumber/core/gherkin/document'
|
19
|
-
features = feature_files.map do |file|
|
20
|
-
Cucumber::Core::Gherkin::Document.new(file, File.read(file))
|
21
|
-
end
|
22
|
-
|
23
|
-
require 'cucumber/mappings'
|
24
|
-
mappings = Mappings.new
|
25
|
-
|
26
|
-
require 'cucumber/formatter/report_adapter'
|
27
|
-
require 'cucumber/formatter/progress'
|
28
|
-
require 'cucumber/formatter/pretty'
|
29
|
-
formatter_options = {
|
30
|
-
skip_profile_information: true,
|
31
|
-
source: true,
|
32
|
-
}
|
33
|
-
formatter = Cucumber::Formatter::Pretty.new(mappings.runtime, STDOUT, formatter_options)
|
34
|
-
report = Cucumber::Formatter::ReportAdapter.new(mappings.runtime, formatter)
|
35
|
-
|
36
|
-
DebugReport = Class.new do
|
37
|
-
def before_test_case(test_case)
|
38
|
-
puts
|
39
|
-
puts test_case.inspect
|
40
|
-
end
|
41
|
-
|
42
|
-
def after_test_case(test_case, result)
|
43
|
-
end
|
44
|
-
|
45
|
-
def before_test_step(test_step)
|
46
|
-
puts ' ' + test_step.inspect
|
47
|
-
end
|
48
|
-
|
49
|
-
def after_test_step(test_step, result)
|
50
|
-
end
|
51
|
-
|
52
|
-
def after_suite
|
53
|
-
end
|
54
|
-
end
|
55
|
-
#report = DebugReport.new
|
56
|
-
|
57
|
-
require 'cucumber/core/test/tag_filter'
|
58
|
-
execute features, mappings, report, [[Cucumber::Core::Test::TagFilter, ['~@jruby']]]
|
59
|
-
report.after_suite
|
60
|
-
end
|
@@ -1,57 +0,0 @@
|
|
1
|
-
Feature: Cucumber command line
|
2
|
-
In order to find out what step definitions need to be implemented
|
3
|
-
Developers should always see what step definition is missing
|
4
|
-
|
5
|
-
@spawn
|
6
|
-
Scenario: Get info at arbitrary levels of nesting
|
7
|
-
Given a file named "features/call_undefined_step_from_step_def.feature" with:
|
8
|
-
"""
|
9
|
-
Feature: Calling undefined step
|
10
|
-
|
11
|
-
Scenario: Call from feature
|
12
|
-
Given this directly called step does not exist
|
13
|
-
|
14
|
-
Scenario: Call directly
|
15
|
-
Given a step that calls an undefined step
|
16
|
-
|
17
|
-
Scenario: Call via another
|
18
|
-
Given a step that calls a step that calls an undefined step
|
19
|
-
"""
|
20
|
-
And a file named "features/step_definitions/steps.rb" with:
|
21
|
-
"""
|
22
|
-
Given /^a step that calls an undefined step$/ do
|
23
|
-
step 'this does not exist'
|
24
|
-
end
|
25
|
-
|
26
|
-
Given /^a step that calls a step that calls an undefined step$/ do
|
27
|
-
step 'a step that calls an undefined step'
|
28
|
-
end
|
29
|
-
"""
|
30
|
-
When I run `cucumber --strict -q features/call_undefined_step_from_step_def.feature`
|
31
|
-
Then it should fail with exactly:
|
32
|
-
"""
|
33
|
-
Feature: Calling undefined step
|
34
|
-
|
35
|
-
Scenario: Call from feature
|
36
|
-
Given this directly called step does not exist
|
37
|
-
Undefined step: "this directly called step does not exist" (Cucumber::Undefined)
|
38
|
-
features/call_undefined_step_from_step_def.feature:4:in `Given this directly called step does not exist'
|
39
|
-
|
40
|
-
Scenario: Call directly
|
41
|
-
Given a step that calls an undefined step
|
42
|
-
Undefined step: "this does not exist" (Cucumber::Undefined)
|
43
|
-
./features/step_definitions/steps.rb:2:in `/^a step that calls an undefined step$/'
|
44
|
-
features/call_undefined_step_from_step_def.feature:7:in `Given a step that calls an undefined step'
|
45
|
-
|
46
|
-
Scenario: Call via another
|
47
|
-
Given a step that calls a step that calls an undefined step
|
48
|
-
Undefined step: "this does not exist" (Cucumber::Undefined)
|
49
|
-
./features/step_definitions/steps.rb:2:in `/^a step that calls an undefined step$/'
|
50
|
-
./features/step_definitions/steps.rb:6:in `/^a step that calls a step that calls an undefined step$/'
|
51
|
-
features/call_undefined_step_from_step_def.feature:10:in `Given a step that calls a step that calls an undefined step'
|
52
|
-
|
53
|
-
3 scenarios (3 undefined)
|
54
|
-
3 steps (3 undefined)
|
55
|
-
0m0.012s
|
56
|
-
|
57
|
-
"""
|
@@ -1,337 +0,0 @@
|
|
1
|
-
@wire
|
2
|
-
Feature: Wire Protocol
|
3
|
-
In order to be allow Cucumber to touch my app in intimate places
|
4
|
-
As a developer on platform which doesn't support Ruby
|
5
|
-
I want a low-level protocol which Cucumber can use to run steps within my app
|
6
|
-
|
7
|
-
#
|
8
|
-
# Cucumber's wire protocol is an implementation of Cucumber's internal
|
9
|
-
# 'programming language' abstraction, and allows step definitions to be
|
10
|
-
# implemented and invoked on any platform.
|
11
|
-
#
|
12
|
-
# Communication is over a TCP socket, which Cucumber connects to when it finds
|
13
|
-
# a definition file with the .wire extension in the step_definitions folder
|
14
|
-
# (or other load path). Note that these files are rendered with ERB when loaded.
|
15
|
-
#
|
16
|
-
# Cucumber sends the following request messages out over the wire:
|
17
|
-
#
|
18
|
-
# * step_matches : this is used to find out whether the wire server has a
|
19
|
-
# definition for a given step
|
20
|
-
# * invoke : this is used to ask for a step definition to be invoked
|
21
|
-
# * begin_scenario : signals that cucumber is about to execute a scenario
|
22
|
-
# * end_scenario : signals that cucumber has finished executing a scenario
|
23
|
-
# * snippet_text : requests a snippet for an undefined step
|
24
|
-
#
|
25
|
-
# Every message supports two standard responses:
|
26
|
-
# * success : which expects different arguments (sometimes none at
|
27
|
-
# all) 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 signaling 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.
|
38
|
-
#
|
39
|
-
|
40
|
-
Background:
|
41
|
-
Given a file named "features/wired.feature" with:
|
42
|
-
"""
|
43
|
-
Feature: High strung
|
44
|
-
Scenario: Wired
|
45
|
-
Given we're all wired
|
46
|
-
|
47
|
-
"""
|
48
|
-
And a file named "features/step_definitions/some_remote_place.wire" with:
|
49
|
-
"""
|
50
|
-
host: localhost
|
51
|
-
port: 54321
|
52
|
-
|
53
|
-
"""
|
54
|
-
|
55
|
-
|
56
|
-
#
|
57
|
-
# # Request: 'step_matches'
|
58
|
-
#
|
59
|
-
# When the features have been parsed, Cucumber will send a step_matches
|
60
|
-
# message to ask the wire server if it can match a step name. This happens for
|
61
|
-
# each of the steps in each of the features.
|
62
|
-
#
|
63
|
-
# The wire server replies with an array of StepMatch objects.
|
64
|
-
|
65
|
-
Scenario: Dry run finds no step match
|
66
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
67
|
-
| request | response |
|
68
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
69
|
-
When I run `cucumber --dry-run --no-snippets -f progress`
|
70
|
-
And it should pass with:
|
71
|
-
"""
|
72
|
-
U
|
73
|
-
|
74
|
-
1 scenario (1 undefined)
|
75
|
-
1 step (1 undefined)
|
76
|
-
|
77
|
-
"""
|
78
|
-
|
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.
|
85
|
-
Scenario: Dry run finds a step match
|
86
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
87
|
-
| request | response |
|
88
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
89
|
-
When I run `cucumber --dry-run -f progress`
|
90
|
-
And it should pass with:
|
91
|
-
"""
|
92
|
-
-
|
93
|
-
|
94
|
-
1 scenario (1 skipped)
|
95
|
-
1 step (1 skipped)
|
96
|
-
|
97
|
-
"""
|
98
|
-
|
99
|
-
# Optionally, the StepMatch can also contain a source reference, and a native
|
100
|
-
# regexp string which will be used by some formatters.
|
101
|
-
Scenario: Step matches returns details about the remote step definition
|
102
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
103
|
-
| request | response |
|
104
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
|
105
|
-
When I run `cucumber -f stepdefs --dry-run`
|
106
|
-
Then it should pass with:
|
107
|
-
"""
|
108
|
-
-
|
109
|
-
|
110
|
-
we.* # MyApp.MyClass:123
|
111
|
-
|
112
|
-
1 scenario (1 skipped)
|
113
|
-
1 step (1 skipped)
|
114
|
-
|
115
|
-
"""
|
116
|
-
And the stderr should not contain anything
|
117
|
-
|
118
|
-
|
119
|
-
#
|
120
|
-
# # Request: 'invoke'
|
121
|
-
#
|
122
|
-
# Assuming a StepMatch was returned for a given step name, when it's time to
|
123
|
-
# invoke that step definition, Cucumber will send an invoke message.
|
124
|
-
#
|
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
|
136
|
-
#
|
137
|
-
|
138
|
-
# ## Pending Steps
|
139
|
-
#
|
140
|
-
@spawn
|
141
|
-
Scenario: Invoke a step definition which is pending
|
142
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
143
|
-
| request | response |
|
144
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
145
|
-
| ["begin_scenario"] | ["success"] |
|
146
|
-
| ["invoke",{"id":"1","args":[]}] | ["pending", "I'll do it later"] |
|
147
|
-
| ["end_scenario"] | ["success"] |
|
148
|
-
When I run `cucumber -f pretty -q`
|
149
|
-
And it should pass with:
|
150
|
-
"""
|
151
|
-
Feature: High strung
|
152
|
-
|
153
|
-
Scenario: Wired
|
154
|
-
Given we're all wired
|
155
|
-
I'll do it later (Cucumber::Pending)
|
156
|
-
features/wired.feature:3:in `Given we're all wired'
|
157
|
-
|
158
|
-
1 scenario (1 pending)
|
159
|
-
1 step (1 pending)
|
160
|
-
|
161
|
-
"""
|
162
|
-
|
163
|
-
# ## Passing Steps
|
164
|
-
#
|
165
|
-
Scenario: Invoke a step definition which passes
|
166
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
167
|
-
| request | response |
|
168
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
169
|
-
| ["begin_scenario"] | ["success"] |
|
170
|
-
| ["invoke",{"id":"1","args":[]}] | ["success"] |
|
171
|
-
| ["end_scenario"] | ["success"] |
|
172
|
-
When I run `cucumber -f progress`
|
173
|
-
And it should pass with:
|
174
|
-
"""
|
175
|
-
.
|
176
|
-
|
177
|
-
1 scenario (1 passed)
|
178
|
-
1 step (1 passed)
|
179
|
-
|
180
|
-
"""
|
181
|
-
|
182
|
-
# ## Failing Steps
|
183
|
-
#
|
184
|
-
# When an invoked step definition fails, it can return details of the exception
|
185
|
-
# in the reply to invoke. This causes a Cucumber::WireSupport::WireException to be
|
186
|
-
# raised.
|
187
|
-
#
|
188
|
-
# Valid arguments are:
|
189
|
-
# * message (mandatory)
|
190
|
-
# * exception
|
191
|
-
# * backtrace
|
192
|
-
#
|
193
|
-
# See the specs for Cucumber::WireSupport::WireException for more details
|
194
|
-
#
|
195
|
-
@spawn
|
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
|
-
@spawn
|
295
|
-
Scenario: Wire server returns snippets for a step that didn't match
|
296
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
297
|
-
| request | response |
|
298
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
|
299
|
-
| ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["success","foo()\n bar;\nbaz"] |
|
300
|
-
| ["begin_scenario"] | ["success"] |
|
301
|
-
| ["end_scenario"] | ["success"] |
|
302
|
-
When I run `cucumber -f pretty`
|
303
|
-
Then the stderr should not contain anything
|
304
|
-
And it should pass with:
|
305
|
-
"""
|
306
|
-
Feature: High strung
|
307
|
-
|
308
|
-
Scenario: Wired # features/wired.feature:2
|
309
|
-
Given we're all wired # features/wired.feature:3
|
310
|
-
|
311
|
-
1 scenario (1 undefined)
|
312
|
-
1 step (1 undefined)
|
313
|
-
"""
|
314
|
-
And the output should contain:
|
315
|
-
"""
|
316
|
-
|
317
|
-
You can implement step definitions for undefined steps with these snippets:
|
318
|
-
|
319
|
-
foo()
|
320
|
-
bar;
|
321
|
-
baz
|
322
|
-
|
323
|
-
"""
|
324
|
-
|
325
|
-
#
|
326
|
-
# # Bad Response
|
327
|
-
#
|
328
|
-
Scenario: Unexpected response
|
329
|
-
Given there is a wire server running on port 54321 which understands the following protocol:
|
330
|
-
| request | response |
|
331
|
-
| ["begin_scenario"] | ["yikes"] |
|
332
|
-
| ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
|
333
|
-
When I run `cucumber -f pretty`
|
334
|
-
Then the stdout should contain:
|
335
|
-
"""
|
336
|
-
undefined method `handle_yikes'
|
337
|
-
"""
|