busser-behave 0.1.3

data/vendor/behave/features/step.use_step_library.feature

@@ -0,0 +1,44 @@
+Feature: Use a step library
+
+  As a tester
+  I want to use steps from one or more step libraries
+  To simplify the reuse of problem domain specific steps in multiple projects.
+
+
+  Scenario: Use a simple step library
+    Given a new working directory
+    And an empty file named "step_library1/__init__.py"
+    And a file named "step_library1/alice_steps.py" with:
+      """
+      from behave import step
+
+      @step('I meet Alice')
+      def step_meet_alice(context):
+          pass
+      """
+    And a file named "step_library1/bob_steps.py" with:
+      """
+      from behave import step
+
+      @step('I meet Bob')
+      def step_meet_bob(context):
+          pass
+      """
+    And a file named "features/steps/use_step_library.py" with:
+      """
+      from step_library1 import alice_steps, bob_steps
+      """
+    And a file named "features/example_use_step_library.feature" with:
+      """
+      Feature:
+        Scenario:
+          Given I meet Alice
+          And   I meet Bob
+      """
+    When I run "behave -f plain features/example_use_step_library.feature"
+    Then it should pass with:
+        """
+        1 feature passed, 0 failed, 0 skipped
+        1 scenario passed, 0 failed, 0 skipped
+        2 steps passed, 0 failed, 0 skipped, 0 undefined
+        """

data/vendor/behave/features/step_dialect.generic_steps.feature

@@ -0,0 +1,189 @@
+Feature: Step dialect for generic steps
+
+  As a test/story writer
+  I want to have a possibility to use generic steps
+  So that I can execute a sequence of steps without BDD keywords (Given/When/Then)
+
+  . SPECIFICATION: Generic step
+  .   * Prefix each step with a '*' (asterisk/star) character to mark it as step
+  .   * Provide step-functions/step definition with "@step" decorator
+
+
+  @setup
+  Scenario: Feature Setup
+    Given a new working directory
+    And a file named "features/steps/steps.py" with:
+        """
+        from behave import step
+
+        @step('{word:w} step passes')
+        def step_passes(context, word):
+            pass
+
+        @step('{word:w} step passes with "{param}"')
+        def step_passes_with_param(context, word, param):
+            pass
+
+        @step('a multi-line text step with')
+        def step_with_multiline_text(context):
+            assert context.text is not None, "REQUIRE: multi-line text"
+
+        @step('a step fails with "{param}"')
+        def step_fails_with_param(context, param=None):
+            assert False, "XFAIL-STEP: %s" % param
+
+        @step('a step fails')
+        def step_fails(context):
+            assert False, "XFAIL-STEP"
+
+        @step('a table step with')
+        def step_with_table(context):
+            assert context.table, "REQUIRES: table"
+            context.table.require_columns(["name", "age"])
+        """
+
+
+  Scenario: Simple step-by-step example
+
+      * a step passes
+      * another step passes
+
+
+  Scenario: Simple step-by-step example 2
+    Given a file named "features/generic_steps.feature" with:
+        """
+        Feature:
+          Scenario:
+            * a step passes
+            * another step passes
+            * a step passes with "Alice"
+            * another step passes with "Bob"
+        """
+    When I run "behave -f plain -T features/generic_steps.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        4 steps passed, 0 failed, 0 skipped
+        """
+    And the command output should contain:
+        """
+        Feature:
+          Scenario:
+            * a step passes ... passed
+            * another step passes ... passed
+            * a step passes with "Alice" ... passed
+            * another step passes with "Bob" ... passed
+        """
+
+  Scenario: Simple step-by-step example with failing steps
+    Given a file named "features/generic_steps.failing.feature" with:
+        """
+        Feature:
+          Scenario:
+            * a step passes
+            * a step fails with "Alice"
+            * a step fails with "Bob"
+            * another step passes
+        """
+    When I run "behave -f plain -T features/generic_steps.failing.feature"
+    Then it should fail with:
+        """
+        0 scenarios passed, 1 failed, 0 skipped
+        1 step passed, 1 failed, 2 skipped
+        """
+    And the command output should contain:
+        """
+        Feature:
+          Scenario:
+            * a step passes ... passed
+            * a step fails with "Alice" ... failed
+        """
+
+
+  Scenario: Simple step-by-step example with scenario description
+
+    CASE: Ensure that first step is discovered after last description line.
+
+      Given a file named "features/generic_steps.with_description.feature" with:
+        '''
+        Feature:
+          Scenario:
+
+            First scenario description line.
+            Second scenario description line.
+
+              * a step passes
+              * another step passes
+        '''
+      When I run "behave -f plain -T features/generic_steps.with_description.feature"
+      Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        2 steps passed, 0 failed, 0 skipped
+        """
+
+
+  Scenario: Simple step-by-step example with multi-line text
+    Given a file named "features/generic_steps.with_text.feature" with:
+      '''
+      Feature:
+        Scenario:
+          * a step passes
+          * a multi-line text step with:
+              """
+              First line of multi-line text.
+              Second-line of multi-line text.
+              """
+          * another step passes with "Charly"
+      '''
+    When I run "behave -f plain -T features/generic_steps.with_text.feature"
+    Then it should pass with:
+      """
+      1 scenario passed, 0 failed, 0 skipped
+      3 steps passed, 0 failed, 0 skipped
+      """
+    And the command output should contain:
+      '''
+      Feature:
+
+        Scenario:
+          * a step passes ... passed
+          * a multi-line text step with ... passed
+            """
+            First line of multi-line text.
+            Second-line of multi-line text.
+            """
+          * another step passes with "Charly" ... passed
+      '''
+
+  Scenario: Simple step-by-step example with table
+    Given a file named "features/generic_steps.with_table.feature" with:
+      '''
+      Feature:
+        Scenario:
+          * a step passes
+          * a table step with:
+              | name  | age |
+              | Alice | 10  |
+              | Bob   | 12  |
+          * another step passes with "Dodo"
+      '''
+    When I run "behave -f plain -T features/generic_steps.with_table.feature"
+    Then it should pass with:
+      """
+      1 scenario passed, 0 failed, 0 skipped
+      3 steps passed, 0 failed, 0 skipped
+      """
+    And the command output should contain:
+      '''
+      Feature:
+        Scenario:
+          * a step passes ... passed
+          * a table step with ... passed
+              | name  | age |
+              | Alice | 10  |
+              | Bob   | 12  |
+          * another step passes with "Dodo" ... passed
+      '''
+
+

data/vendor/behave/features/step_dialect.given_when_then.feature

@@ -0,0 +1,89 @@
+Feature: Step Dialect for BDD Steps with Given/When/Then Keywords
+
+  In order to execute a sequence of steps with BDD keywords (Given/When/Then)
+  As a test/story writer
+  I want to have the possibility to express myself.
+  
+  . NOTE:
+  .   * More details are provided in other features.
+
+
+  Scenario: Simple example
+
+    Normally preferred style with BDD keywords.
+    Note that BDD keywords are dependent on language settings.
+
+      Given a step passes
+      When a step passes
+      And a step passes
+      Then a step passes
+      And a step passes
+      But a step passes
+
+
+  Scenario: Simple example (with lower-case keywords)
+
+    Alternative style with lower-case BDD keywords.
+
+      given a step passes
+      when a step passes
+      and a step passes
+      then a step passes
+      and a step passes
+      but a step passes
+
+
+  Scenario: Step usage example with details by running behave
+    Given a new working directory
+    And a file named "features/steps/steps.py" with:
+        """
+        from behave import given, when, then, step
+
+        @given('a step passes')
+        def given_step_passes(context):
+            pass
+
+        @when('a step passes')
+        def when_step_passes(context):
+            pass
+
+        @then('a step passes')
+        def then_step_passes(context):
+            pass
+
+        @step('a step passes with "{param}"')
+        def step_passes_with_param(context, param):
+            pass
+
+        @step('another step passes')
+        def step_passes(context):
+            pass
+
+        @step('another step passes with "{param}"')
+        def step_passes(context, param):
+            pass
+        """
+    And a file named "features/basic_steps.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given a step passes
+            And another step passes
+            When a step passes with "Alice"
+            Then another step passes with "Bob"
+        """
+    When I run "behave -f plain -T features/basic_steps.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        4 steps passed, 0 failed, 0 skipped
+        """
+    And the command output should contain:
+        """
+        Feature:
+          Scenario:
+            Given a step passes ... passed
+            And another step passes ... passed
+            When a step passes with "Alice" ... passed
+            Then another step passes with "Bob" ... passed
+        """

data/vendor/behave/features/step_param.builtin_types.with_float.feature

@@ -0,0 +1,239 @@
+@sequential
+Feature: Parse data types in step parameters (type transformation)
+
+  As a test writer
+  I want write steps with parameter that should have floating-point data types
+  So that I can just use the step parameter with the correct type
+
+  behave uses the parse module (inverse of Python string.format).
+  Therefore, the following ``parse types`` for floats are already supported:
+
+    ===== =========================================== ============= ================================
+    Type  Characters Matched (regex class)            Output Type   Example(s)
+    ===== =========================================== ============= ================================
+     %     Percentage (converted to value/100.0)       float         51.2%
+     f     Fixed-point numbers                         float         1.23  -1.45
+     e     Floating-point numbers with exponent        float         1.1e-10  -12.3E+5
+     g     General number format (either d, f or e)    float         123  1.23  -1.45E+12
+    ===== =========================================== ============= ================================
+
+
+    SEE ALSO:
+      * http://pypi.python.org/pypi/parse
+      * string.format: http://docs.python.org/library/string.html#format-string-syntax
+
+
+  @setup
+  Scenario: Feature Setup
+    Given a new working directory
+    And a file named "features/steps/float_param_steps.py" with:
+        """
+        from behave import then, step
+        class NotMatched(object): pass
+
+        @step('a float param with "{value:g}"')
+        def step_float_param_with(context, value):
+            assert type(value) is float
+            context.value = value
+
+        @step('a float param with "{value}"')
+        def step_float_param_otherwise(context, value):
+            context.value = NotMatched
+
+        @step('a generic float param with "{value:g}"')
+        def step_generic_float_param_with(context, value):
+            step_float_param_with(context, value)
+
+        @step('a generic float param with "{value}"')
+        def step_generic_float_param_otherwise(context, value):
+            step_float_param_otherwise(context, value)
+
+        @step('a float with exponent param with "{value:e}"')
+        def step_float_with_exponent_param_with(context, value):
+            step_float_param_with(context, value)
+
+        @step('a float with exponent param with "{value}"')
+        def step_float_with_exponent_param_otherwise(context, value):
+            step_float_param_otherwise(context, value)
+
+        @step('a percentage param with "{value:%}"')
+        def step_percentage_param_with(context, value):
+            step_float_param_with(context, value)
+
+        @step('a percentage param with "{value}"')
+        def step_percentage_param_otherwise(context, value):
+            step_float_param_otherwise(context, value)
+
+        @step('a fixed-point number param with "{value:f}"')
+        def step_fixed_point_number_param_with(context, value):
+            step_float_param_with(context, value)
+
+        @step('a fixed-point number param with "{value}"')
+        def step_fixed_point_number_param_otherwise(context, value):
+            step_float_param_otherwise(context, value)
+
+        @then('the value should be {outcome} as float number')
+        def step_value_should_be_matched_as_float_number(context, outcome):
+            expected_type = float
+            if outcome == "matched":
+                assert type(context.value) is expected_type, \
+                        "Unexpected type: %s" % type(context.value)
+            else:
+                assert context.value is NotMatched
+
+        @then('the value should be {outcome} as float number with "{expected:g}"')
+        def step_value_should_be_matched_as_float_number_with_expected(context, outcome, expected):
+            step_value_should_be_matched_as_float_number(context, outcome)
+            assert context.value == expected, \
+                "FAILED: value(%s) == expected(%s)" % (context.value, expected)
+        """
+
+
+  Scenario: Float parameter values with type "%" (percentage)
+    Given a file named "features/example.float_param.with_percent.feature" with:
+        """
+        Feature: Float parameter values with type "%" (percentage)
+
+          Scenario Outline: Good cases
+            Given a percentage param with "<Value>"
+            Then the value should be matched as float number with "<Expected Value>"
+
+          Examples:
+            | Value  | Expected Value | Case |
+            |    0%  |    0     | Zero       |
+            |   20%  |    0.2   | Positive number   |
+            |  120%  |    1.2   | Larger than 100%  |
+            | 10.5%  |    0.105 | Float number    |
+            |  -10%  |   -0.1   | Negative number |
+            |  +10%  |    0.1   | With plus sign  |
+
+
+          Scenario Outline: Bad cases (not matched)
+            Given a percentage param with "<Value>"
+            Then the value should be <Outcome> as float number
+
+          Examples:
+            | Value  | Outcome     | Reason |
+            |   123  | not-matched | Percentage sign is missing |
+            |  1.23  | not-matched | Float number without percentage sign |
+            |  Alice | not-matched | Not a number |
+        """
+    When I run "behave -f plain features/example.float_param.with_percent.feature"
+    Then it should pass with:
+        """
+        9 scenarios passed, 0 failed, 0 skipped
+        """
+
+
+  Scenario: Fixed-point parameter values with type "f"
+    Given a file named "features/example.float_param.with_type_f.feature" with:
+        """
+        Feature: Float parameter values with type "f" (fixed-point number)
+
+          Scenario Outline: Good cases
+            Given a fixed-point number param with "<Value>"
+            Then the value should be matched as float number with "<Expected Value>"
+
+          Examples:
+            | Value  | Expected Value | Case     |
+            |   0.23 |    0.23  |                |
+            |   1.23 |    1.23  |                |
+            | 123.45 |  123.45  |                |
+            |  +1.23 |    1.23  | With plus sign |
+            |  -1.23 |   -1.23  | Negative float |
+
+
+          Scenario Outline: Bad cases (not matched)
+            Given a fixed-point number param with "<Value>"
+            Then the value should be <Outcome> as float number
+
+          Examples:
+            | Value   | Outcome     | Reason |
+            |   123   | not-matched | Integer number             |
+            | 1.23E-7 | not-matched | Float number with exponent |
+            |  Alice  | not-matched | Not a number               |
+        """
+    When I run "behave -f plain features/example.float_param.with_type_f.feature"
+    Then it should pass with:
+        """
+        8 scenarios passed, 0 failed, 0 skipped
+        """
+
+
+  Scenario: Float with exponent parameter values with type "e"
+    Given a file named "features/example.float_param.with_type_e.feature" with:
+        """
+        Feature: Float parameter values with type "e" (float with exponents)
+
+          Scenario Outline: Good cases
+            Given a float with exponent param with "<Value>"
+            Then the value should be matched as float number with "<Expected Value>"
+
+          Examples:
+            | Value     | Expected Value | Case                |
+            |  1.0E-10  |   1E-10   | With mantisse, negative exponent |
+            |  1.23E+5  |   123E3   | Exponent with plus sign  |
+            |  123.0E+3 |  1.23E5   | Exponent with plus sign  |
+            | -1.23E5   |  -123E3   | Negative number with mantisse and exponent |
+            |     INF   |    +INF   | Infinity (INF)           |
+            |    +INF   |     INF   |                          |
+            |    -INF   |    -INF   |                          |
+            |    +inf   |     INF   | Lower-case special names |
+
+
+          Scenario Outline: Bad cases (not matched)
+            Given a float with exponent param with "<Value>"
+            Then the value should be <Outcome> as float number
+
+          Examples:
+            | Value   | Outcome     | Reason |
+            |   1E10  | not-matched | Without mantissa |
+            |   1.E10 | not-matched | Short mantissa   |
+            |   123   | not-matched | Integer number   |
+            |  Alice  | not-matched | Not a number     |
+        """
+    When I run "behave -f plain features/example.float_param.with_type_e.feature"
+    Then it should pass with:
+        """
+        12 scenarios passed, 0 failed, 0 skipped
+        """
+
+
+  Scenario: Generic float parameter values with type "g"
+    Given a file named "features/example.float_param.with_type_g.feature" with:
+        """
+        Feature: Float parameter values with type "g" (generic float)
+
+          Scenario Outline: Good cases
+            Given a generic float param with "<Value>"
+            Then the value should be matched as float number with "<Expected Value>"
+
+          Examples:
+            | Value     | Expected Value | Case                |
+            |        1  |   1.0     | Integer number format    |
+            |     1E10  |   1.0E10  | Float with exponent and shortened mantissa |
+            |   1.23E5  |   1.23E5  | Float with exponent and mantissa |
+            |   1.23e5  |   1.23E5  | Float with exponent and mantissa (lower-case) |
+            |  1.0E-10  |   1E-10   | With mantisse, negative exponent |
+            |  1.23E+5  |   123E3   | Exponent with plus sign   |
+            |  123.0E+3 |   1.23E5  | Exponent with plus sign   |
+            | -1.23E5   |  -123E3   | Negative number with mantisse and exponent |
+
+
+          Scenario Outline: Bad cases (not matched)
+            Given a generic float param with "<Value>"
+            Then the value should be <Outcome> as float number
+
+          Examples:
+            | Value   | Outcome     | Reason             |
+            | 0b101   | not-matched | Binary number      |
+            | 0o17    | not-matched | Octal number       |
+            | 0x1A    | not-matched | Hexadecimal number |
+            | 1.E10   | not-matched | Short mantissa     |
+            | Alice   | not-matched | Not a number       |
+        """
+    When I run "behave -f plain features/example.float_param.with_type_g.feature"
+    Then it should pass with:
+        """
+        13 scenarios passed, 0 failed, 0 skipped
+        """