cucumber 0.4.5.rc2 → 0.5.0

data/.gitignore

@@ -16,3 +16,4 @@ examples/self_test/tmp
 .#*
 .idea
 rerun.txt
+._*

data/History.txt

@@ -1,24 +1,33 @@
-== In Git
+== 0.5.0 2009-12-15
+
+We're bumping to 0.5.0 for this release since all of the Rails code has now moved to a new gem - cucumber-rails.
+Please see History.txt in cucumber-rails for details about what's new on the Rails side.
 
 === New features
+* "Given" in Dutch is now aliased to "Gegeven" or "Stel". (Iain Hecker)
+* New --i18n option to list keywords in various languages. (Aslak Hellesøy)
 * Added a Tcl example using Sam Stephenson's ruby-tcl (Aslak Hellesøy)
 * Added * as a synonym for Given/When/Then/And/But (for all i18n languages). (#462 Aslak Hellesøy)
 * The HTML formatter produces a much nicer report, with TextMate link integration. (Rob Aldred)
+* Wire protocol now supports table arguments, step definition source & regexp, snippets, pending, table diffing (Matt Wynne)
 
 === Changed Features
 * Per-word trailing-space setting for step keywords using '<'.  See 'fr' in languages.yml for example. (#525 Gregory Hnatiuk)
-* --language is deprecated and will be removed in 0.5.0: http://wiki.github.com/aslakhellesoy/cucumber/spoken-languages (Aslak Hellesøy)
 * Formatters will no longer be passed File objects. They must use ensure_io, ensure_file or ensure_dir. (Aslak Hellesøy)
 
 === Bugfixes
+* Exception messages are properly escaped in the HTML report. (Aslak Hellesøy)
+* Improved UTF-8 support for Windows. (Aslak Hellesøy)
 * Make #element_at / #table_at work on Webrat 0.6.0. This is now deprecated it in favour of #tableish from the cucumber-rails gem. (Aslak Hellesøy)
 * JUnit formatter not handling multiline table steps inside Scenario Outlines (#538 Matt Wynne)
 * Pending in scenario outline is red (#399 Matt Wynne)
 * Allow optional step arguments to play happily with step transforms (Rob Holland)
 * Regex escape the path when filtering the backtrace (Corey Donohoe & Simon Rozet)
+* Add gem dependency on JSON gem, required by wire protocol (#533 Matt Wynne)
 
 === Removed Features
 * All Rails-related code is in a separate gem: cucumber-rails. Install that if you're working with Rails. (#483 Aslak Hellesøy)
+* --language is removed: http://wiki.github.com/aslakhellesoy/cucumber/spoken-languages (Aslak Hellesøy)
 
 == 0.4.4 2009-11-13
 

data/Rakefile

@@ -16,17 +16,18 @@ begin
     gem.authors = ["Aslak Hellesøy"]
     gem.rubyforge_project = "rspec"
 
-    gem.add_dependency 'term-ansicolor', '1.0.4'
-    gem.add_dependency 'treetop', '1.4.2'
-    gem.add_dependency 'polyglot', '0.2.9'
-    gem.add_dependency 'builder', '2.1.2'
-    gem.add_dependency 'diff-lcs', '1.1.2'
-
-    gem.add_development_dependency 'nokogiri', '1.4.0'
-    gem.add_development_dependency 'prawn', '0.5.1'
-    gem.add_development_dependency 'rspec', '1.2.9'
-    gem.add_development_dependency 'spork', '0.7.3'
-    
+    gem.add_dependency 'term-ansicolor', '>= 1.0.4'
+    gem.add_dependency 'treetop', '>= 1.4.2'
+    gem.add_dependency 'polyglot', '>= 0.2.9'
+    gem.add_dependency 'builder', '>= 2.1.2'
+    gem.add_dependency 'diff-lcs', '>= 1.1.2'
+    gem.add_dependency defined?(JRUBY_VERSION) ? 'json_pure' : 'json', '>= 1.2.0'
+
+    gem.add_development_dependency 'nokogiri', '>= 1.4.0'
+    gem.add_development_dependency 'prawn', '>= 0.5.1'
+    gem.add_development_dependency 'rspec', '>= 1.2.9'
+    gem.add_development_dependency 'spork', '>= 0.7.4'
+
     extend Cucumber::Formatter::ANSIColor
     gem.post_install_message = <<-POST_INSTALL_MESSAGE
 

data/VERSION.yml

@@ -1,5 +1,4 @@
 --- 
-:patch: 5
+:patch: 0
 :major: 0
-:minor: 4
-:build: rc2
+:minor: 5

data/cucumber.gemspec

@@ -5,11 +5,11 @@
 
 Gem::Specification.new do |s|
   s.name = %q{cucumber}
-  s.version = "0.4.5.rc2"
+  s.version = "0.5.0"
 
-  s.required_rubygems_version = Gem::Requirement.new("> 1.3.1") if s.respond_to? :required_rubygems_version=
+  s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
   s.authors = ["Aslak Helles\303\270y"]
-  s.date = %q{2009-12-07}
+  s.date = %q{2009-12-15}
   s.default_executable = %q{cucumber}
   s.description = %q{A BDD tool written in Ruby}
   s.email = %q{cukes@googlegroups.com}
@@ -366,6 +366,7 @@ Gem::Specification.new do |s|
      "features/unicode_table.feature",
      "features/usage_and_stepdefs_formatter.feature",
      "features/wire_protocol.feature",
+     "features/wire_protocol_table_diffing.feature",
      "features/work_in_progress.feature",
      "gem_tasks/contributors.rake",
      "gem_tasks/environment.rake",
@@ -524,8 +525,10 @@ Gem::Specification.new do |s|
      "spec/cucumber/treetop_parser/test_dos.feature",
      "spec/cucumber/treetop_parser/with_comments.feature",
      "spec/cucumber/treetop_parser/with_tags.feature",
+     "spec/cucumber/wire_support/wire_exception_spec.rb",
      "spec/cucumber/wire_support/wire_language_spec.rb",
      "spec/cucumber/wire_support/wire_packet_spec.rb",
+     "spec/cucumber/wire_support/wire_step_definition_spec.rb",
      "spec/cucumber/world/pending_spec.rb",
      "spec/spec.opts",
      "spec/spec_helper.rb"
@@ -536,7 +539,7 @@ Gem::Specification.new do |s|
 
                      (::)   U P G R A D I N G    (::)
 
-Thank you for installing cucumber-0.4.5.rc2.
+Thank you for installing cucumber-0.5.0.
 Please be sure to read http://wiki.github.com/aslakhellesoy/cucumber/upgrading
 for important information about this release. Happy cuking!
 
@@ -583,8 +586,10 @@ for important information about this release. Happy cuking!
      "spec/cucumber/rb_support/regexp_argument_matcher_spec.rb",
      "spec/cucumber/step_match_spec.rb",
      "spec/cucumber/step_mother_spec.rb",
+     "spec/cucumber/wire_support/wire_exception_spec.rb",
      "spec/cucumber/wire_support/wire_language_spec.rb",
      "spec/cucumber/wire_support/wire_packet_spec.rb",
+     "spec/cucumber/wire_support/wire_step_definition_spec.rb",
      "spec/cucumber/world/pending_spec.rb",
      "spec/spec_helper.rb",
      "examples/i18n/ar/features/step_definitons/calculator_steps.rb",
@@ -706,36 +711,39 @@ for important information about this release. Happy cuking!
     s.specification_version = 3
 
     if Gem::Version.new(Gem::RubyGemsVersion) >= Gem::Version.new('1.2.0') then
-      s.add_runtime_dependency(%q<term-ansicolor>, ["= 1.0.4"])
-      s.add_runtime_dependency(%q<treetop>, ["= 1.4.2"])
-      s.add_runtime_dependency(%q<polyglot>, ["= 0.2.9"])
-      s.add_runtime_dependency(%q<builder>, ["= 2.1.2"])
-      s.add_runtime_dependency(%q<diff-lcs>, ["= 1.1.2"])
-      s.add_development_dependency(%q<nokogiri>, ["= 1.4.0"])
-      s.add_development_dependency(%q<prawn>, ["= 0.5.1"])
-      s.add_development_dependency(%q<rspec>, ["= 1.2.9"])
-      s.add_development_dependency(%q<spork>, ["= 0.7.3"])
+      s.add_runtime_dependency(%q<term-ansicolor>, [">= 1.0.4"])
+      s.add_runtime_dependency(%q<treetop>, [">= 1.4.2"])
+      s.add_runtime_dependency(%q<polyglot>, [">= 0.2.9"])
+      s.add_runtime_dependency(%q<builder>, [">= 2.1.2"])
+      s.add_runtime_dependency(%q<diff-lcs>, [">= 1.1.2"])
+      s.add_runtime_dependency(%q<json>, [">= 1.2.0"])
+      s.add_development_dependency(%q<nokogiri>, [">= 1.4.0"])
+      s.add_development_dependency(%q<prawn>, [">= 0.5.1"])
+      s.add_development_dependency(%q<rspec>, [">= 1.2.9"])
+      s.add_development_dependency(%q<spork>, [">= 0.7.4"])
     else
-      s.add_dependency(%q<term-ansicolor>, ["= 1.0.4"])
-      s.add_dependency(%q<treetop>, ["= 1.4.2"])
-      s.add_dependency(%q<polyglot>, ["= 0.2.9"])
-      s.add_dependency(%q<builder>, ["= 2.1.2"])
-      s.add_dependency(%q<diff-lcs>, ["= 1.1.2"])
-      s.add_dependency(%q<nokogiri>, ["= 1.4.0"])
-      s.add_dependency(%q<prawn>, ["= 0.5.1"])
-      s.add_dependency(%q<rspec>, ["= 1.2.9"])
-      s.add_dependency(%q<spork>, ["= 0.7.3"])
+      s.add_dependency(%q<term-ansicolor>, [">= 1.0.4"])
+      s.add_dependency(%q<treetop>, [">= 1.4.2"])
+      s.add_dependency(%q<polyglot>, [">= 0.2.9"])
+      s.add_dependency(%q<builder>, [">= 2.1.2"])
+      s.add_dependency(%q<diff-lcs>, [">= 1.1.2"])
+      s.add_dependency(%q<json>, [">= 1.2.0"])
+      s.add_dependency(%q<nokogiri>, [">= 1.4.0"])
+      s.add_dependency(%q<prawn>, [">= 0.5.1"])
+      s.add_dependency(%q<rspec>, [">= 1.2.9"])
+      s.add_dependency(%q<spork>, [">= 0.7.4"])
     end
   else
-    s.add_dependency(%q<term-ansicolor>, ["= 1.0.4"])
-    s.add_dependency(%q<treetop>, ["= 1.4.2"])
-    s.add_dependency(%q<polyglot>, ["= 0.2.9"])
-    s.add_dependency(%q<builder>, ["= 2.1.2"])
-    s.add_dependency(%q<diff-lcs>, ["= 1.1.2"])
-    s.add_dependency(%q<nokogiri>, ["= 1.4.0"])
-    s.add_dependency(%q<prawn>, ["= 0.5.1"])
-    s.add_dependency(%q<rspec>, ["= 1.2.9"])
-    s.add_dependency(%q<spork>, ["= 0.7.3"])
+    s.add_dependency(%q<term-ansicolor>, [">= 1.0.4"])
+    s.add_dependency(%q<treetop>, [">= 1.4.2"])
+    s.add_dependency(%q<polyglot>, [">= 0.2.9"])
+    s.add_dependency(%q<builder>, [">= 2.1.2"])
+    s.add_dependency(%q<diff-lcs>, [">= 1.1.2"])
+    s.add_dependency(%q<json>, [">= 1.2.0"])
+    s.add_dependency(%q<nokogiri>, [">= 1.4.0"])
+    s.add_dependency(%q<prawn>, [">= 0.5.1"])
+    s.add_dependency(%q<rspec>, [">= 1.2.9"])
+    s.add_dependency(%q<spork>, [">= 0.7.4"])
   end
 end
 

data/cucumber.yml

@@ -4,7 +4,7 @@ rerun_opts = rerun.to_s.strip.empty? ? "--format progress features" : "--format
 std_opts = "#{rerun_opts} --format rerun --out rerun.txt --strict --tags ~@wip"
 %>
 default: <%= std_opts %>
-jruby: <%= std_opts %>,~@spork
+jruby: <%= std_opts %>,~@spork,~@wire
 run_code_run: <%= std_opts %>,~@spork
 windows_mri: <%= std_opts %>,~@spork
 wip: --tags @wip:3 --wip features

data/features/language_help.feature

@@ -3,7 +3,7 @@ Feature: Language help
   I want to be able to get help on the language from the CLI
 
   Scenario: Get help for Portuguese language
-    When I run cucumber -l pt help
+    When I run cucumber --i18n pt help
     Then it should pass with
       """
       | name             | Portuguese                              |
@@ -21,7 +21,7 @@ Feature: Language help
 
       """
   Scenario: List languages
-    When I run cucumber -l help
+    When I run cucumber --i18n help
     Then it should pass with
       """
       | ar      | Arabic                 | العربية              |

data/features/wire_protocol.feature

@@ -5,19 +5,26 @@ Feature: Wire Protocol
   I want a low-level protocol which Cucumber can use to run steps within my app
 
   #
-  # Cucumber's wire protocol is an implementation of Cucumber's internal 'programming language' abstraction,
-  # and allows step definitions to be implemented and invoked on any platform.
+  # Cucumber's wire protocol is an implementation of Cucumber's internal
+  # 'programming language' abstraction, and allows step definitions to be
+  # implemented and invoked on any platform.
   #
-  # Communication is over a TCP socket, which Cucumber connects to when it finds a definition file with the
-  # .wire extension in the step_definitions folder (or other load path).
+  # Communication is over a TCP socket, which Cucumber connects to when it finds
+  # a definition file with the .wire extension in the step_definitions folder
+  # (or other load path).
   #
-  # There are currently two messages which Cucumber sends over the wire:
+  # Cucumber currently sends the following messages over the wire:
   #
-  #   * step_matches : this is used to find out whether the wire end has a definition for a given step
-  #   * invoke       : this is used to ask for a step definition to be invoked
+  #   * step_matches   : this is used to find out whether the wire end has a
+  #                      definition for a given step
+  #   * invoke         : this is used to ask for a step definition to be invoked
+  #   * begin_scenario : signals that cucumber is about to execute a scenario
+  #   * end_scenario   : signals that cucumber has finished executing a scenario
+  #   * snippet_text   : requests a snippet for an undefined step
   #
-  # Message packets are formatted as JSON-encoded strings, with a newline character signalling the end of a
-  # packet. These messages are described below, with examples.
+  # Message packets are formatted as JSON-encoded strings, with a newline
+  # character signalling the end of a packet. These messages are described
+  # below, with examples.
   #
 
   Background:
@@ -39,16 +46,18 @@ Feature: Wire Protocol
   #
   # step_matches
   #
-  # When the features have been parsed, Cucumber will send a step_matches message to ask the wire end
-  # if it can match a step name. This happens for each of the steps in each of the features.
-  # The wire end replies with a step_match array, containing the IDs of any step definitions that could
-  # be invoked for the given step name.
+  # When the features have been parsed, Cucumber will send a step_matches
+  # message to ask the wire end if it can match a step name. This happens for
+  # each of the steps in each of the features.
+  #
+  # The wire end replies with a step_match array, containing the IDs of any step
+  # definitions that could be invoked for the given step name.
 
   Scenario: Dry run finds no step match
     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"}] | ["step_matches",[]] |
-    When I run cucumber --dry-run -f progress features
+    When I run cucumber --dry-run -f progress
     And it should pass with
       """
       U
@@ -58,17 +67,18 @@ Feature: Wire Protocol
 
       """
 
-  # When a step match is returned, it contains an identifier for the step definition to be used
-  # later when referring to this step definition again if it needs to be invoked. The identifier
-  # can take any form (as long as it's within a string) and is simply used for the wire end's own
-  # reference.
-  # The step match also contains any argument values as parsed out by the wire end's own regular
-  # expression or other argument matching process.
+  # When a step match is returned, it contains an identifier for the step
+  # definition to be used later when referring to this step definition again if
+  # it needs to be invoked. The identifier can take any form (as long as it's
+  # within a string) and is simply used for the wire end's own reference.
+  #
+  # The step match also contains any argument values as parsed out by the wire
+  # end's own regular expression or other argument matching process.
   Scenario: Dry run finds a step match
     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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
-    When I run cucumber --dry-run -f progress features
+    When I run cucumber --dry-run -f progress
     And it should pass with
       """
       -
@@ -78,16 +88,60 @@ Feature: Wire Protocol
 
       """
 
+  # Optionally, the step match can also contain the a source reference, and a
+  # native regexp string which will be used by some formatters
+  Scenario: Step matches returns details about the remote step definition
+    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"}] | ["step_matches",[{"id":"1", "args":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
+    When I run cucumber -f stepdefs --dry-run
+    Then STDERR should be empty
+    And it should pass with
+      """
+      -
+
+      we.*    # MyApp.MyClass:123
+
+      1 scenario (1 skipped)
+      1 step (1 skipped)
+
+      """
+
 
   #
   # invoke
   #
-  # Assuming a step_match was returned for a given step name, when it's time to invoke that
-  # step definition, Cucumber will send an invoke message.
-  # The message contains the ID of the step definition, as returned by the wire end from the
-  # step_matches call, along with the arguments that were parsed from the step name during the
-  # same step_matches call.
-  # The wire end will reply with either a step_failed or a success message.
+  # Assuming a step_match was returned for a given step name, when it's time to
+  # invoke that step definition, Cucumber will send an invoke message.
+  #
+  # The message contains the ID of the step definition, as returned by the wire
+  # end from the step_matches call, along with the arguments that were parsed
+  # from the step name during the same step_matches call.
+  #
+  # The wire end will reply with either a step_failed, success, or pending message.
+
+  # The message argument which accompanies the pending message is optional
+  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"}] | ["step_matches",[{"id":"1", "args":[]}]] |
+      | ["begin_scenario",null]                              | ["success", null]                        |
+      | ["invoke",{"id":"1","args":[]}]                      | ["pending", "I'll do it later"]          |
+      | ["end_scenario",null]                                | ["success", null]                        |
+    When I run cucumber -f pretty -q
+    And it should pass with
+      """
+
+
+        Scenario: Wired
+          Given we're all wired
+            I'll do it later (Cucumber::Pending)
+            features/wired.feature:2: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:
@@ -96,7 +150,7 @@ Feature: Wire Protocol
       | ["begin_scenario",null]                              | ["success",null]                         |
       | ["invoke",{"id":"1","args":[]}]                      | ["success",null]                         |
       | ["end_scenario",null]                                | ["success",null]                         |
-    When I run cucumber -f progress --backtrace features
+    When I run cucumber -f progress
     And it should pass with
       """
       .
@@ -106,17 +160,18 @@ Feature: Wire Protocol
 
       """
 
-  # When a step definition fails, it can return details of the exception in the reply to invoke. These
-  # will then be passed by Cucumber to the formatters for display to the user.
+  # When an invoked step definition fails, it can return details of the exception
+  # in the reply to invoke. These will then be passed by Cucumber to the formatters
+  # for display to the user.
   #
   Scenario: Invoke a step definition which fails
     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"}] | ["step_matches",[{"id":"1", "args":[]}]]         |
-      | ["begin_scenario",null]                              | ["success",null]                                 |
-      | ["invoke",{"id":"1","args":[]}]                      | ["step_failed",{"message":"The wires are down"}] |
-      | ["end_scenario",null]                                | ["success",null]                                 |
-    When I run cucumber -f progress features
+      | request                                              | response                                                                                   |
+      | ["step_matches",{"name_to_match":"we're all wired"}] | ["step_matches",[{"id":"1", "args":[]}]]                                                   |
+      | ["begin_scenario",null]                              | ["success",null]                                                                           |
+      | ["invoke",{"id":"1","args":[]}]                      | ["step_failed",{"message":"The wires are down", "exception":"Some.Foreign.ExceptionType"}] |
+      | ["end_scenario",null]                                | ["success",null]                                                                           |
+    When I run cucumber -f progress
     Then STDERR should be empty
     And it should fail with
       """
@@ -124,7 +179,7 @@ Feature: Wire Protocol
 
       (::) failed steps (::)
 
-      The wires are down (Cucumber::WireSupport::WireException)
+      The wires are down (Some.Foreign.ExceptionType from localhost:54321)
       features/wired.feature:2:in `Given we're all wired'
 
       Failing Scenarios:
@@ -137,24 +192,27 @@ Feature: Wire Protocol
 
   # Imagine we have a step definition like:
   #
-  #     Given /we're all (.*)/ do |what_we_are|
+  #     Given /we're all (.*)/ do | what_we_are |
   #     end
   #
-  # When this step definition matches the step name in our feature, the word 'wired' will be parsed as an
-  # argument.
+  # When this step definition matches the step name in our feature, the word
+  # 'wired' will be parsed as an argument.
   #
-  # Cucumber expects this StepArgument 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)
+  # Cucumber expects this StepArgument 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)
   #
-  Scenario: Invoke a step definition which takes arguments (and passes)
+  Scenario: Invoke a step definition which takes string arguments (and 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"}] | ["step_matches",[{"id":"1", "args":[{"val":"wired", "pos":10}]}]] |
       | ["begin_scenario",null]                              | ["success",null]                                                  |
       | ["invoke",{"id":"1","args":["wired"]}]               | ["success",null]                                                  |
       | ["end_scenario",null]                                | ["success",null]                                                  |
-    When I run cucumber -f progress --backtrace features
+    When I run cucumber -f progress
     Then STDERR should be empty
     And it should pass with
       """
@@ -165,12 +223,73 @@ Feature: Wire Protocol
 
       """
 
+  # When the step has a multiline table argument, it will be passed with the
+  # invoke message as a string - a serialized JSON array of array of strings.
+  # In the following scenario our step definition takes two arguments - one
+  # captures the "we're" and the other takes the table.
+  Scenario: Invoke a step definition which takes table arguments (and passes)
+    Given a file named "features/wired_on_tables.feature" with:
+      """
+        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:"}]                       | ["step_matches",[{"id":"1", "args":[{"val":"we're", "pos":0}]}]] |
+      | ["begin_scenario",null]                                               | ["success",null]                                                 |
+      | ["invoke",{"id":"1","args":["we're",[["wired"],["high"],["happy"]]]}] | ["success",null]                                                 |
+      | ["end_scenario",null]                                                 | ["success",null]                                                 |
+    When I run cucumber -f progress features/wired_on_tables.feature
+    Then STDERR should be empty
+    And it should pass with
+      """
+      .
+
+      1 scenario (1 passed)
+      1 step (1 passed)
+
+      """
+
+
+  #
+  # snippets
+  #
+  Scenario: Wire server returns snippets for a step that didn't match
+    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"}]                                             | ["step_matches",[]]                   |
+      | ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["snippet_text","foo()\n  bar;\nbaz"] |
+      | ["begin_scenario",null]                                                                          | ["success",null]                      |
+      | ["end_scenario",null]                                                                            | ["success",null]                      |
+    When I run cucumber -f pretty
+    And it should pass with
+      """
+
+
+        Scenario: Wired         # features/wired.feature:1
+          Given we're all wired # features/wired.feature:2
+
+      1 scenario (1 undefined)
+      1 step (1 undefined)
+
+      You can implement step definitions for undefined steps with these snippets:
+
+      foo()
+        bar;
+      baz
+
+
+      """
+
 
   Scenario: Unexpected response
     Given there is a wire server running on port 54321 which understands the following protocol:
-      | request                                              | response   |
-      | ["begin_scenario",null]                              | ["yikes"]  |
-    When I run cucumber -f progress features
+      | request                 | response  |
+      | ["begin_scenario",null] | ["yikes"] |
+    When I run cucumber -f progress
     Then STDERR should match
       """
       undefined method `handle_yikes'