cucumber 2.1.0 → 2.2.0

data/features/docs/wire_protocol/erb_configuration.feature

@@ -1,56 +0,0 @@
-@wire
-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/docs/wire_protocol/handle_unexpected_response.feature

@@ -1,30 +0,0 @@
-@wire
-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/docs/wire_protocol/invoke_message.feature

@@ -1,216 +0,0 @@
-@wire
-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:
-      """
-      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/docs/wire_protocol/readme.md

@@ -1,26 +0,0 @@
-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 WirePacket 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::WireSupport::WirePacket 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::WireSupport::WireException to be raised.
-
-Some messages support more responses - see individual scenarios for details.

data/features/docs/wire_protocol/snippets_message.feature

@@ -1,51 +0,0 @@
-@wire
-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:
-      """
-
-      You can implement step definitions for undefined steps with these snippets:
-
-      foo()
-        bar;
-      baz
-
-      """

data/features/docs/wire_protocol/step_matches_message.feature

@@ -1,81 +0,0 @@
-@wire
-Feature: Step matches message
-
-  When the features have been parsed, Cucumber will send a `step_matches`
-  message to ask the wire server if it can match a step name. This happens for
-  each of the steps in each of the features.
-
-  The wire server replies with an array of StepMatch objects.
-
-  When each StepMatch is returned, it contains the following data:
-
-  * `id` - identifier for the step definition to be used later when if it
-  needs to be invoked. The identifier can be any string value and
-  is simply used for the wire server's own reference.
-  * `args` - any argument values as captured by the wire end's own regular
-  expression (or other argument matching) process.
-
-  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: 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"}] | ["success",[]] |
-    When I run `cucumber --dry-run --no-snippets -f progress`
-    And it should pass with:
-      """
-      U
-
-      1 scenario (1 undefined)
-      1 step (1 undefined)
-
-      """
-
-  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"}] | ["success",[{"id":"1", "args":[]}]] |
-    When I run `cucumber --dry-run -f progress`
-    And it should pass with:
-      """
-      -
-
-      1 scenario (1 skipped)
-      1 step (1 skipped)
-
-      """
-
-  Scenario: Step matches returns details about the remote step definition
-
-    Optionally, the StepMatch can also contain a source reference, and a native
-    regexp string which will be used by some formatters.
-
-    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":[], "source":"MyApp.MyClass:123", "regexp":"we.*"}]] |
-    When I run `cucumber -f stepdefs --dry-run`
-    Then it should pass with:
-      """
-      -
-
-      we.*   # MyApp.MyClass:123
-
-      1 scenario (1 skipped)
-      1 step (1 skipped)
-
-      """
-    And the stderr should not contain anything
-