cucumber 2.0.0.rc.4 → 2.0.0.rc.5

data/features/docs/defining_steps/nested_steps.feature

@@ -127,3 +127,52 @@ Feature: Nested Steps
       1 scenario (1 failed)
       1 step (1 failed)
       """
+
+  Scenario: Undefined nested step
+    Given a file named "features/call_undefined_step_from_step_def.feature" with:
+      """
+      Feature: Calling undefined step
+
+        Scenario: Call directly
+          Given a step that calls an undefined step
+
+        Scenario: Call via another
+          Given a step that calls a step that calls an undefined step
+      """
+    And a file named "features/step_definitions/steps.rb" with:
+      """
+      Given /^a step that calls an undefined step$/ do
+        step 'this does not exist'
+      end
+
+      Given /^a step that calls a step that calls an undefined step$/ do
+        step 'a step that calls an undefined step'
+      end
+      """
+    When I run `cucumber -q features/call_undefined_step_from_step_def.feature`
+    Then it should fail with exactly:
+      """
+      Feature: Calling undefined step
+
+        Scenario: Call directly
+          Given a step that calls an undefined step
+            Undefined dynamic step: "this does not exist" (Cucumber::UndefinedDynamicStep)
+            ./features/step_definitions/steps.rb:2:in `/^a step that calls an undefined step$/'
+            features/call_undefined_step_from_step_def.feature:4:in `Given a step that calls an undefined step'
+
+        Scenario: Call via another
+          Given a step that calls a step that calls an undefined step
+            Undefined dynamic step: "this does not exist" (Cucumber::UndefinedDynamicStep)
+            ./features/step_definitions/steps.rb:2:in `/^a step that calls an undefined step$/'
+            ./features/step_definitions/steps.rb:6:in `/^a step that calls a step that calls an undefined step$/'
+            features/call_undefined_step_from_step_def.feature:7:in `Given a step that calls a step that calls an undefined step'
+
+      Failing Scenarios:
+      cucumber features/call_undefined_step_from_step_def.feature:3
+      cucumber features/call_undefined_step_from_step_def.feature:6
+
+      2 scenarios (2 failed)
+      2 steps (2 failed)
+      0m0.012s
+
+      """

data/features/docs/exception_in_after_step_hook.feature

@@ -94,7 +94,7 @@ Feature: Exception in AfterStep Block
           Given this step passes # features/step_definitions/steps.rb:1
 
       Failing Scenarios:
-      cucumber features/naughty_step_in_scenario_outline.feature:9 # Scenario Outline: Naughty Step, Examples (row 2)
+      cucumber features/naughty_step_in_scenario_outline.feature:9 # Scenario Outline: Naughty Step, Examples (#2)
 
       4 scenarios (1 failed, 3 passed)
       4 steps (4 passed)

data/features/docs/exception_in_around_hook.feature

@@ -0,0 +1,80 @@
+Feature: Exceptions in Around Hooks
+
+  Around hooks are awkward beasts to handle internally.
+
+  Right now, if there's an error in your Around hook before you call `block.call`,
+  we won't even print the steps for the scenario.
+
+  This is because that `block.call` invokes all the logic that would tell Cucumber's
+  UI about the steps in your scenario. If we never reach that code, we'll never be
+  told about them.
+
+  There's another scenario to consider, where the exception occurs after the steps
+  have been run. How would we want to report in that case?
+
+  Scenario: Exception before the test case is run
+    Given the standard step definitions
+    And a file named "features/support/env.rb" with:
+      """
+      Around do |scenario, block|
+        fail "this should be reported"
+        block.call
+      end
+      """
+    And a file named "features/test.feature" with:
+      """
+      Feature:
+        Scenario:
+          Given this step passes
+      """
+    When I run `cucumber -q`
+    Then it should fail with exactly:
+      """
+      Feature: 
+
+        Scenario: 
+        this should be reported (RuntimeError)
+        ./features/support/env.rb:2:in `Around'
+      
+      Failing Scenarios:
+      cucumber features/test.feature:2
+      
+      1 scenario (1 failed)
+      0 steps
+      0m0.012s
+
+      """
+
+  Scenario: Exception after the test case is run
+    Given the standard step definitions
+    And a file named "features/support/env.rb" with:
+      """
+      Around do |scenario, block|
+        block.call
+        fail "this should be reported"
+      end
+      """
+    And a file named "features/test.feature" with:
+      """
+      Feature:
+        Scenario:
+          Given this step passes
+      """
+    When I run `cucumber -q`
+    Then it should fail with exactly:
+      """
+      Feature: 
+
+        Scenario: 
+          Given this step passes
+            this should be reported (RuntimeError)
+            ./features/support/env.rb:3:in `Around'
+      
+      Failing Scenarios:
+      cucumber features/test.feature:2
+      
+      1 scenario (1 failed)
+      1 step (1 passed)
+      0m0.012s
+
+      """

data/features/docs/formatters/json_formatter.feature

@@ -82,6 +82,14 @@ Feature: JSON output formatter
         Scenario:
           Given I embed data directly
 
+        Scenario Outline:
+          Given I embed data directly
+
+	  Examples:
+	  | dummy |
+	  |  1    |
+	  |  2    |
+
       """
     And a file named "features/out_scenario_out_scenario_outline.feature" with:
       """
@@ -613,7 +621,7 @@ Feature: JSON output formatter
 
   @spawn
   Scenario: embedding data directly
-    When I run `cucumber -b --format json features/embed_data_directly.feature`
+    When I run `cucumber -b --format json -x features/embed_data_directly.feature`
     Then it should pass with JSON:
     """
     [
@@ -652,6 +660,62 @@ Feature: JSON output formatter
                 }
               }
             ]
+          },
+          {
+            "keyword": "Scenario Outline",
+            "name": "",
+            "line": 11,
+            "description": "",
+            "id": "an-embed-data-directly-feature;;;2",
+            "type": "scenario",
+            "steps": [
+              {
+                "keyword": "Given ",
+                "name": "I embed data directly",
+                "line": 11,
+                "embeddings": [
+                  {
+                    "mime_type": "mime-type",
+                    "data": "YWJj"
+                  }
+                ],
+                "match": {
+                  "location": "features/step_definitions/json_steps.rb:10"
+                },
+                "result": {
+                  "status": "passed",
+                  "duration": 1
+                }
+              }
+            ]
+          },
+          {
+            "keyword": "Scenario Outline",
+            "name": "",
+            "line": 12,
+            "description": "",
+            "id": "an-embed-data-directly-feature;;;3",
+            "type": "scenario",
+            "steps": [
+              {
+                "keyword": "Given ",
+                "name": "I embed data directly",
+                "line": 12,
+                "embeddings": [
+                  {
+                    "mime_type": "mime-type",
+                    "data": "YWJj"
+                  }
+                ],
+                "match": {
+                  "location": "features/step_definitions/json_steps.rb:10"
+                },
+                "result": {
+                  "status": "passed",
+                  "duration": 1
+                }
+              }
+            ]
           }
         ]
       }

data/features/docs/formatters/junit_formatter.feature

@@ -274,3 +274,43 @@ You *must* specify --out DIR for the junit formatter
       </testsuite>
 
       """ 
+
+  Scenario: one feature, one scenario outline, two examples: one passing, one failing with --expand option
+    When I run `cucumber --expand --format junit --out tmp/ features/scenario_outline.feature`
+    Then it should fail with exactly:
+      """
+
+      """
+    And the junit output file "tmp/TEST-features-scenario_outline.xml" should contain:
+      """
+      <?xml version="1.0" encoding="UTF-8"?>
+      <testsuite failures="1" errors="0" skipped="0" tests="2" time="0.05" name="Scenario outlines">
+      <testcase classname="Scenario outlines" name="Using scenario outlines (outline example : | passes |)" time="0.05">
+        <system-out/>
+        <system-err/>
+      </testcase>
+      <testcase classname="Scenario outlines" name="Using scenario outlines (outline example : | fails |)" time="0.05">
+        <failure message="failed Using scenario outlines (outline example : | fails |)" type="failed">
+          <![CDATA[Scenario Outline: Using scenario outlines
+      
+      Example row: | fails |
+      
+      Message:
+      ]]>
+          <![CDATA[ (RuntimeError)
+      ./features/step_definitions/steps.rb:4:in `/^this step fails$/'
+      features/scenario_outline.feature:9:in `Given this step fails'
+      features/scenario_outline.feature:4:in `Given this step <type>']]>
+        </failure>
+        <system-out/>
+        <system-err/>
+      </testcase>
+        <system-out>
+          <![CDATA[]]>
+        </system-out>
+        <system-err>
+          <![CDATA[]]>
+        </system-err>
+      </testsuite>
+
+      """ 

data/features/docs/{wire_protocol_erb.feature → wire_protocol/erb_configuration.feature}

@@ -1,6 +1,6 @@
 @wire
-Feature: Wire Protocol with ERB
-  In order to be allow Cucumber to touch my app in intimate places
+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

data/features/docs/wire_protocol/handle_unexpected_response.feature

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

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