busser-behave 0.1.3

data/vendor/behave/features/tags.default_tags.feature

@@ -0,0 +1,104 @@
+Feature: Default Tags
+
+  As a tester
+  I want to define a number of default tags in a configuration file
+  So that I do not have to specify these tags each time on the command-line.
+
+  . NOTES:
+  .   * default tags are normally used to exclude/disable tag(s)
+  .   * command-line tags override the default tags
+  .   * default tags can be disabled by using the following expression
+  .     on the command-line: behave --tags=-xxx ... (where xxx is an unknown tag)
+
+
+    @setup
+    Scenario: Test Setup
+      Given a new working directory
+      And a file named "features/one.feature" with:
+        """
+        Feature:
+          @not_implemented
+          Scenario: Alice
+            Given missing step passes
+
+          @foo
+          Scenario: Bob
+            Given another step passes
+            Then a step passes
+        """
+      And a file named "features/steps/passing_steps.py" with:
+        """
+        from behave import step
+
+        @step('{word:w} step passes')
+        def step_passes(context, word):
+            pass
+        """
+
+  Scenario: Use default tags with one tag
+    Given a file named "behave.ini" with:
+      """
+      [behave]
+      show_skipped = false
+      default_tags = -@not_implemented
+      """
+    When I run "behave -f plain features"
+    Then it should pass with:
+      """
+      1 scenario passed, 0 failed, 1 skipped
+      2 steps passed, 0 failed, 1 skipped, 0 undefined
+      """
+    And the command output should contain "Scenario: Bob"
+    But the command output should not contain "Scenario: Alice"
+
+
+  Scenario: Override default tag on command-line
+    Given a file named "behave.ini" with:
+      """
+      [behave]
+      show_skipped = false
+      default_tags = -@not_implemented
+      """
+    When I run "behave -f plain --tags=not_implemented features"
+    Then it should pass with:
+      """
+      1 scenario passed, 0 failed, 1 skipped
+      1 step passed, 0 failed, 2 skipped, 0 undefined
+      """
+    And the command output should contain "Scenario: Alice"
+    But the command output should not contain "Scenario: Bob"
+
+  Scenario: Use default tags with two tags
+    Given a file named "behave.ini" with:
+      """
+      [behave]
+      show_skipped = false
+      default_tags = -@not_implemented -@xfail
+      # tag logic := not @not_implemented and not @xfail
+      """
+    When I run "behave -f plain features"
+    Then it should pass with:
+      """
+      1 scenario passed, 0 failed, 1 skipped
+      2 steps passed, 0 failed, 1 skipped, 0 undefined
+      """
+    And the command output should contain "Scenario: Bob"
+    But the command output should not contain "Scenario: Alice"
+
+
+  Scenario: Override default tags on command-line
+    Given a file named "behave.ini" with:
+      """
+      [behave]
+      show_skipped = false
+      default_tags = -@not_implemented -@xfail
+      # tag logic := not @not_implemented and not @xfail
+      """
+    When I run "behave -f plain --tags=not_implemented,foo features"
+    Then it should pass with:
+      """
+      2 scenarios passed, 0 failed, 0 skipped
+      3 steps passed, 0 failed, 0 skipped, 0 undefined
+      """
+    And the command output should contain "Scenario: Alice"
+    But the command output should contain "Scenario: Bob"

data/vendor/behave/features/tags.tag_expression.feature

@@ -0,0 +1,105 @@
+Feature: Tag Expression
+
+  As a tester
+  I want to select a subset of all features/scenarios by using tags
+  And I want to include and/or exclude some tags
+  So that I can focus on the "important" scenarios (and features).
+
+  . SPECIFICATION:
+  .   * a tag expression is a boolean expression
+  .   * a tag expression supports the operators: and, or, not
+  .   * a tag expression is structured as:
+  .       (or_expr1) and (or_expr2) and ...
+  .
+  . EXAMPLES:
+  .   | Tag logic         | Tag expression  | Comment |
+  .   | @foo              | @foo            | Select elements with @foo tag |
+  .   | @foo              |  foo            | Same, '@' is optional.        |
+  .   | not @foo          | -@foo           | Use minus for "not".          |
+  .   | not @foo          | ~foo            | Same, use tilde instead of minus |
+  .   | @foo or @bar      | @foo,@bar       | Use comma for "or".           |
+  .   | @foo and @bar     | @foo @bar       | Use space separated terms.    |
+  .   | @foo or  not @bar | @foo,-@bar      |                               |
+  .   | @foo and not @bar | @foo -@bar      |                               |
+
+
+  Scenario: Select @foo
+    Given the tag expression "@foo"
+    Then the tag expression selects elements with tags:
+        | tags         | selected? |
+        |              |   no      |
+        | @foo         |   yes     |
+        | @other       |   no      |
+        | @foo @other  |   yes     |
+
+
+  Scenario: Tag expression with 0..1 tags
+    Given the model elements with name and tags:
+        | name | tags         | Comment |
+        | S0   |              | Untagged    |
+        | S1   | @foo         | With 1 tag  |
+        | S2   | @other       |             |
+        | S3   | @foo @other  | With 2 tags |
+    And note that "are all combinations of 0..2 tags"
+    Then the tag expression selects model elements with:
+        | tag expression | selected?      | Case comment |
+        |                | S0, S1, S2, S3 | Select all (empty tag expression) |
+        |  @foo          | S1, S3         | Select @foo                       |
+        | -@foo          | S0, S2         | not @foo, selects untagged elements |
+    But note that "tag expression variants are also supported"
+    And the tag expression selects model elements with:
+        | tag expression | selected?      | Case comment |
+        |  foo           | S1, S3         |     @foo: '@' is optional     |
+        | -foo           | S0, S2         | not @foo: '@' is optional     |
+        | ~foo           | S0, S2         | not @foo: tilde as minus      |
+        | ~@foo          | S0, S2         | not @foo: '~@' is supported   |
+
+
+  Scenario: Tag expression with two tags (@foo, @bar)
+    Given the model elements with name and tags:
+        | name | tags             | Comment |
+        | S0   |                  | Untagged    |
+        | S1   | @foo             | With 1 tag  |
+        | S2   | @bar             |             |
+        | S3   | @other           |             |
+        | S4   | @foo @bar        | With 2 tags |
+        | S5   | @foo @other      |             |
+        | S6   | @bar @other      |             |
+        | S7   | @foo @bar @other | With 3 tags |
+    And note that "are all combinations of 0..3 tags"
+    Then the tag expression selects model elements with:
+        | tag expression | selected?                      | Case |
+        |                | S0, S1, S2, S3, S4, S5, S6, S7 | Select all            |
+        |  @foo,@bar     | S1, S2, S4, S5, S6, S7         | @foo or @bar          |
+        |  @foo,-@bar    | S0, S1, S3, S4, S5, S7         | @foo or not @bar      |
+        | -@foo,-@bar    | S0, S1, S2, S3, S5, S6         | not @foo or @not @bar |
+        |  @foo  @bar    | S4, S7                         | @foo and @bar         |
+        |  @foo -@bar    | S1, S5                         | @foo and not @bar     |
+        | -@foo -@bar    | S0, S3                         | not @foo and not @bar |
+
+
+  Scenario: Tag expression with three tags (@foo, @bar, @zap)
+    Given the model elements with name and tags:
+        | name | tags                   | Comment |
+        | S0   |                        | Untagged    |
+        | S1   | @foo                   | With 1 tag  |
+        | S2   | @bar                   |             |
+        | S3   | @zap                   |             |
+        | S4   | @other                 |             |
+        | S5   | @foo @bar              | With 2 tags |
+        | S6   | @foo @zap              |             |
+        | S7   | @foo @other            |             |
+        | S8   | @bar @zap              |             |
+        | S9   | @bar @other            |             |
+        | S10  | @zap @other            |             |
+        | S11  | @foo @bar @zap         | With 3 tags |
+        | S12  | @foo @bar @other       |             |
+        | S13  | @foo @zap @other       |             |
+        | S14  | @bar @zap @other       |             |
+        | S15  | @foo @bar @zap @other  | With 4 tags |
+    And note that "are all combinations of 0..4 tags"
+    Then the tag expression selects model elements with:
+        | tag expression   | selected?                   | Case |
+        |  @foo,@bar  @zap | S6, S8, S11, S13, S14, S15  | (@foo or @bar) and @zap |
+        |  @foo,@bar -@zap | S1, S2, S5, S7, S9, S12     | (@foo or @bar) and not @zap |
+        |  @foo,-@bar @zap | S3, S6, S10, S11, S13, S15  | (@foo or not @bar) and @zap |

data/vendor/behave/features/userdata.feature

@@ -0,0 +1,331 @@
+Feature: User-specific Configuration Data (userdata)
+
+  As a test writer
+  I want to provide my own configuration data
+  So that the test suite and/or the environment can be adapted to its needs.
+
+  . MECHANISM:
+  .   * Use -D name=value (--define) option to specify user data on command-line.
+  .   * Specify user data in section "behave.userdata" of "behave.ini"
+  .   * Load/setup user data in before_all() hook (advanced cases)
+  .
+  . USING USER DATA:
+  .   * context.config.userdata (as dict)
+  .
+  . SUPPORTED DATA TYPES (from "behave.ini" and command-line):
+  .   * string
+  .   * bool-like (= "true", if definition has no value)
+
+  @setup
+  Scenario: Feature Setup
+    Given a new working directory
+    And a file named "features/steps/pass_steps.py" with:
+        """
+        from behave import step
+
+        @step('{word:w} step passes')
+        def step_passes(context, word):
+            pass
+        """
+    And a file named "features/steps/userdata_steps.py" with:
+        """
+        from behave import step
+        from hamcrest import assert_that, equal_to
+
+        @step('the following user-data is provided')
+        def step_userdata_is_provided_with_table(context):
+            assert context.table, "REQUIRE: table"
+            context.table.require_columns(["name", "value"])
+            userdata = context.config.userdata
+            for row in context.table.rows:
+                name = row["name"]
+                expected_value = row["value"]
+                if name in userdata:
+                    actual_value = userdata[name]
+                    assert_that(str(actual_value), equal_to(expected_value))
+                else:
+                    assert False, "MISSING: userdata %s" % name
+
+        @step('I modify the user-data with')
+        def step_modify_userdata_with_table(context):
+            assert context.table, "REQUIRE: table"
+            context.table.require_columns(["name", "value"])
+            userdata = context.config.userdata
+            for row in context.table.rows:
+                name = row["name"]
+                value = row["value"]
+                userdata[name] = value
+        """
+
+  @userdata.define
+  Scenario: Use define command-line option
+    Given a file named "features/userdata_ex1.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value |
+              | person1 | Alice |
+              | person2 | Bob   |
+        """
+    And an empty file named "behave.ini"
+    When I run "behave -D person1=Alice --define person2=Bob features/userdata_ex1.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @userdata.define
+  Scenario: Duplicated define with other value overrides first value
+    Given a file named "features/userdata_ex2.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value |
+              | person1 | Bob   |
+        """
+    And an empty file named "behave.ini"
+    When I run "behave -D person1=Alice -D person1=Bob features/userdata_ex2.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @userdata.define
+  Scenario: Use boolean flag as command-line definition
+
+    Ensure that command-line define without value part is a boolean flag.
+
+    Given a file named "features/userdata_ex3.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value |
+              | DEBUG   | true  |
+        """
+    And an empty file named "behave.ini"
+    When I run "behave -D DEBUG features/userdata_ex3.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @userdata.config
+  Scenario: Use user-data from behave configuration file
+    Given a file named "behave.ini" with:
+        """
+        [behave.userdata]
+        person1 = Alice
+        person2 = Bob
+        """
+    When I run "behave features/userdata_ex1.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @userdata.config
+  Scenario: Override user-data from behave configuration file on command-line
+    Given a file named "features/userdata_config2.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value   |
+              | person1 | Charly  |
+              | person2 | Bob     |
+        """
+    And a file named "behave.ini" with:
+        """
+        [behave.userdata]
+        person1 = Alice
+        person2 = Bob
+        """
+    When I run "behave -D person1=Charly features/userdata_config2.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @userdata.config
+  Scenario: Extend user-data from behave configuration file on command-line
+    Given a file named "features/userdata_config3.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value   |
+              | person1 | Alice   |
+              | person2 | Bob     |
+              | person3 | Charly  |
+        """
+    And a file named "behave.ini" with:
+        """
+        [behave.userdata]
+        person1 = Alice
+        person2 = Bob
+        """
+    When I run "behave -D person3=Charly features/userdata_config3.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @userdata.load
+  Scenario: Load user-data configuration in before_all hook (JSON)
+    Given an empty file named "behave.ini"
+    And a file named "features/environment.py" with:
+        """
+        import json
+        import os.path
+
+        def before_all(context):
+            userdata = context.config.userdata
+            configfile = userdata.get("configfile", "userconfig.json")
+            if os.path.exists(configfile):
+                config = json.load(open(configfile))
+                userdata.update(config)
+        """
+    And a file named "userconfig.json" with:
+        """
+        {
+            "person1": "Anna",
+            "person2": "Beatrix"
+        }
+        """
+    And a file named "features/userdata_load1.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value   |
+              | person1 | Anna    |
+              | person2 | Beatrix |
+        """
+    When I run "behave features/userdata_load1.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @userdata.load
+  Scenario: Load user-data configuration in before_all hook (INI)
+    Given a file named "behave.ini" with:
+        """
+        [behave.userdata]
+        configfile     = userconfig.ini
+        config_section = behave.userdata.more
+        """
+    And a file named "userconfig.ini" with:
+        """
+        [behave.userdata.more]
+        person1 = Anna2
+        person2 = Beatrix2
+        """
+    And a file named "features/environment.py" with:
+        """
+        try:
+            import configparser
+        except:
+            import ConfigParser as configparser   # -- PY2
+
+        def before_all(context):
+            userdata = context.config.userdata
+            configfile = userdata.get("configfile", "userconfig.ini")
+            section = userdata.get("config_section", "behave.userdata")
+            parser = configparser.SafeConfigParser()
+            parser.read(configfile)
+            if parser.has_section(section):
+                userdata.update(parser.items(section))
+        """
+    And a file named "features/userdata_load2.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value   |
+              | person1 | Anna2    |
+              | person2 | Beatrix2 |
+        """
+    When I run "behave features/userdata_load2.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """
+
+  @bad_practice
+  @userdata.modify
+  Scenario: Modified user-data is used by the remaining features/scenarios
+
+    Given a file named "features/userdata_modify1.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name    | value   |
+              | person1 | Alice   |
+              | person2 | Bob     |
+            When I modify the user-data with:
+              | name    | value   |
+              | person1 | MODIFIED_VALUE |
+            Then the following user-data is provided:
+              | name    | value   |
+              | person1 | MODIFIED_VALUE |
+              | person2 | Bob     |
+
+          Scenario: Next scenario has modified user-data, too
+            Given the following user-data is provided:
+              | name    | value   |
+              | person1 | MODIFIED_VALUE |
+              | person2 | Bob     |
+        """
+    And a file named "behave.ini" with:
+        """
+        [behave.userdata]
+        person1 = Alice
+        person2 = Bob
+        """
+    When I run "behave features/userdata_modify1.feature"
+    Then it should pass with:
+        """
+        2 scenarios passed, 0 failed, 0 skipped
+        4 steps passed, 0 failed, 0 skipped, 0 undefined
+        """
+    But note that "modifying userdata is BAD-PRACTICE, except in before_all() hook"
+
+  @userdata.case_sensitive
+  Scenario: Loaded user-data from configuration should have case-sensitive keys
+
+    Given a file named "features/userdata_case_sensitive.feature" with:
+        """
+        Feature:
+          Scenario:
+            Given the following user-data is provided:
+              | name            | value |
+              | CamelCaseKey    | 1     |
+              | CAPS_SNAKE_KEY  | 2     |
+              | lower_snake_key | 3     |
+        """
+    And a file named "behave.ini" with:
+        """
+        [behave.userdata]
+        CamelCaseKey = 1
+        CAPS_SNAKE_KEY = 2
+        lower_snake_key = 3
+        """
+    When I run "behave features/userdata_case_sensitive.feature"
+    Then it should pass with:
+        """
+        1 scenario passed, 0 failed, 0 skipped
+        1 step passed, 0 failed, 0 skipped, 0 undefined
+        """