cucumber-wire 0.0.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 193ced89d633c8b78eee1a626af39e9f69a2dbc5
+  data.tar.gz: 42c38717dab358471f86f3f1085c186c2e9df3a6
+SHA512:
+  metadata.gz: d48ac504abae09629fd5baca0dd4b1ef8488623b5da662a1cdfc7b2e8a1808420845f51d1a990def3ee625f211834236814d21f6aa9311d810a0b406031ed343
+  data.tar.gz: b131fcc0318fd1cadec22641e8fac0ab9575db479711a708508c2282b7ba73c2df7859ee3653285364f66daaccf97382dae3dfabc0bf1be1ca306f89ef9a742c

data/.rspec

@@ -0,0 +1 @@
+--color

data/.travis.yml

@@ -0,0 +1,18 @@
+rvm:
+  - 2.2
+  - 2.1
+  - 2.0
+  - 1.9.3
+  - jruby-1.7.12
+
+# whitelist
+branches:
+  only:
+    - master
+
+notifications:
+  email:
+    - cukes-devs@googlegroups.com
+  webhooks:
+    urls: # gitter
+      - https://webhooks.gitter.im/e/dc010332f9d40fcc21c4

data/Gemfile

@@ -0,0 +1,20 @@
+gemspec
+
+source "https://rubygems.org"
+unless ENV['CUCUMBER_USE_RELEASED_GEMS']
+  # cucumber gem
+  cucumber_path = File.expand_path("../../cucumber-ruby", __FILE__)
+  if File.exist?(cucumber_path) && !ENV['CUCUMBER_USE_GIT']
+    gem "cucumber", path: cucumber_path, branch: "remove-wire-protocol-to-plugin"
+  else
+    gem "cucumber", :git => "git://github.com/cucumber/cucumber-ruby.git", branch: "remove-wire-protocol-to-plugin"
+  end
+
+  # cucumber-core gem
+  core_path = File.expand_path("../../cucumber-ruby-core", __FILE__)
+  if File.exist?(core_path) && !ENV['CUCUMBER_USE_GIT_CORE']
+    gem "cucumber-core", path: core_path
+  else
+    gem 'cucumber-core', :git => "git://github.com/cucumber/cucumber-ruby-core.git"
+  end
+end

data/README.md

@@ -0,0 +1 @@
+Work in progress: See https://github.com/cucumber/cucumber-ruby/pull/878

data/Rakefile

@@ -0,0 +1,13 @@
+require 'rubygems'
+require 'bundler'
+Bundler::GemHelper.install_tasks
+
+task default: [:unit_tests, :acceptance_tests]
+
+task :unit_tests do
+  sh "bundle exec rspec"
+end
+
+task :acceptance_tests do
+  sh "bundle exec cucumber"
+end

data/cucumber-wire.gemspec

@@ -0,0 +1,28 @@
+# -*- encoding: utf-8 -*-
+$LOAD_PATH.unshift File.expand_path("../lib", __FILE__)
+
+Gem::Specification.new do |s|
+  s.name        = 'cucumber-wire'
+  s.version     = File.read(File.dirname(__FILE__) + "/lib/cucumber/wire/version")
+  s.authors     = ["Matt Wynne"]
+  s.description = "Wire protocol for Cucumber"
+  s.summary     = "cucumber-wire-#{s.version}"
+  s.email       = 'cukes@googlegroups.com'
+  s.homepage    = "http://cucumber.io"
+  s.platform    = Gem::Platform::RUBY
+  s.license     = "MIT"
+  s.required_ruby_version = ">= 1.9.3"
+
+  s.add_development_dependency 'cucumber', '~> 2.1.0'
+
+  s.add_development_dependency 'bundler',   '>= 1.3.5'
+  s.add_development_dependency 'rake',      '>= 0.9.2'
+  s.add_development_dependency 'rspec',     '~> 3'
+  s.add_development_dependency 'aruba',     '~> 0'
+
+  s.rubygems_version = ">= 1.6.1"
+  s.files            = `git ls-files`.split("\n").reject {|path| path =~ /\.gitignore$/ }
+  s.test_files       = `git ls-files -- spec/*`.split("\n")
+  s.rdoc_options     = ["--charset=UTF-8"]
+  s.require_path     = "lib"
+end

data/features/erb_configuration.feature

@@ -0,0 +1,54 @@
+Feature: ERB configuration
+
+  As a developer on server with multiple users
+  I want to be able to configure which port my wire server runs on
+  So that I can avoid port conflicts
+
+  Background:
+    Given a file named "features/wired.feature" with:
+      """
+      Feature: High strung
+        Scenario: Wired
+          Given we're all wired
+
+      """
+
+  Scenario: ERB is used in the wire file which references an environment variable that is not set
+      Given a file named "features/step_definitions/server.wire" with:
+        """
+        host: localhost
+        port: <%= ENV['PORT'] || 12345 %>
+        """
+      And there is a wire server running on port 12345 which understands the following protocol:
+        | request                                              | response       |
+        | ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
+      When I run `cucumber --dry-run --no-snippets -f progress`
+      Then it should pass with:
+        """
+        U
+
+        1 scenario (1 undefined)
+        1 step (1 undefined)
+
+        """
+
+
+  Scenario: ERB is used in the wire file which references an environment variable
+      Given I have environment variable PORT set to "16816"
+      And a file named "features/step_definitions/server.wire" with:
+        """
+        host: localhost
+        port: <%= ENV['PORT'] || 12345 %>
+        """
+      And there is a wire server running on port 16816 which understands the following protocol:
+        | request                                              | response       |
+        | ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[]] |
+      When I run `cucumber --dry-run --no-snippets -f progress`
+      Then it should pass with:
+        """
+        U
+
+        1 scenario (1 undefined)
+        1 step (1 undefined)
+
+        """

data/features/handle_unexpected_response.feature

@@ -0,0 +1,29 @@
+Feature: Handle unexpected response
+
+  When the server sends us back a message we don't understand, this is how Cucumber will behave.
+
+  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
+
+      """
+
+  Scenario: Unexpected response
+    Given there is a wire server running on port 54321 which understands the following protocol:
+      | request                                              | response                            |
+      | ["begin_scenario"]                                   | ["yikes"]                           |
+      | ["step_matches",{"name_to_match":"we're all wired"}] | ["success",[{"id":"1", "args":[]}]] |
+    When I run `cucumber -f pretty`
+    Then the output should contain:
+      """
+      undefined method `handle_yikes'
+      """

data/features/invoke_message.feature

@@ -0,0 +1,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   |

data/features/readme.md

@@ -0,0 +1,26 @@
+Cucumber's wire protocol 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). Note that these files are rendered with ERB when loaded.
+
+A `Wire::DataPacket` flowing in either direction is formatted as a JSON-encoded
+string, with a newline character signaling the end of a packet. See the
+specs for `Cucumber::Wire::DataPacket` for more details.
+
+Cucumber sends the following request messages out over the wire:
+
+* `step_matches` - Find out whether the wire server has a definition for a step
+* `invoke` - 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
+
+Every message supports two standard responses:
+
+* `success` - expects different arguments (sometimes none at all) depending
+  on the request that was sent.
+* `fail` - causes a Cucumber::Wire::Exception to be raised.
+
+Some messages support more responses - see individual scenarios for details.

data/features/snippets_message.feature

@@ -0,0 +1,47 @@
+Feature: Snippets message
+
+  If a step doesn't match, Cucumber will ask the wire server to return a snippet of code for a
+  step definition.
+
+  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: 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"}]                                             | ["success",[]]                   |
+      | ["snippet_text",{"step_keyword":"Given","multiline_arg_class":"","step_name":"we're all wired"}] | ["success","foo()\n  bar;\nbaz"] |
+      | ["begin_scenario"]                                                                               | ["success"]                      |
+      | ["end_scenario"]                                                                                 | ["success"]                      |
+    When I run `cucumber -f pretty`
+    Then the stderr should not contain anything
+    And it should pass with:
+      """
+      Feature: High strung
+
+        Scenario: Wired         # features/wired.feature:2
+          Given we're all wired # features/wired.feature:3
+
+      1 scenario (1 undefined)
+      1 step (1 undefined)
+      """
+    And the output should contain:
+      """
+      foo()
+        bar;
+      baz
+
+      """