cucumber 3.0.0.pre.2 → 4.0.0.rc.5

data/examples/watir/cucumber.yml

@@ -1 +0,0 @@
-default: --format html --out report.html --format pretty

data/examples/watir/features/search.feature

@@ -1,12 +0,0 @@
-Feature: Search
-  In order to learn more
-  As an information seeker
-  I want to find more information
-
-  Scenario: Find what I'm looking for
-    Given I am on the Google search page
-    When I search for "cucumber github"
-    Then I should see
-      """
-      GitHub
-      """

data/examples/watir/features/step_definitions/search_steps.rb

@@ -1,26 +0,0 @@
-# Full Watir API: http://wtr.rubyforge.org/rdoc/
-# Full RSpec API: http://rspec.rubyforge.org/
-
-Given 'I am on the Google search page' do
-  @browser.goto 'http://www.google.com/'
-end
-
-When(/I search for "(.*)"/) do |query|
-  @browser.text_field(:name, 'q').set(query)
-  @browser.button(:name, 'btnG').click
-end
-
-Then(/I should see/) do |text|
-  @browser.text.should =~ /#{text}/m
-end
-
-# To avoid step definitions that are tightly coupled to your user interface,
-# consider creating classes for your pages - such as this:
-# http://github.com/cucumber/cucumber/tree/v0.1.15/examples/watir/features/step_definitons/search_steps.rb
-#
-# You may keep the page classes along your steps, or even better, put them in separate files, e.g.
-# support/pages/google_search.rb
-#
-# This technique is called "Page Objects", and you can read more about it here:
-# http://github.com/marekj/watirloo/tree/master
-# We're not using this technique here, since we want to illustrate the basics only.

data/examples/watir/features/support/env.rb

@@ -1,35 +0,0 @@
-begin require 'rspec/expectations'; rescue LoadError; require 'spec/expectations'; end
-
-browser = nil
-
-if ENV['FIREFOX']
-  require 'watir-webdriver'
-  Browser = Watir::Browser
-  browser = Browser.new :ff
-else
-  case RUBY_PLATFORM
-  when /darwin/
-    require 'safariwatir'
-    Browser = Watir::Safari
-  when /win32|mingw/
-    require 'watir'
-    Browser = Watir::IE
-  when /java/
-    require 'celerity'
-    Browser = Celerity::Browser
-  else
-    raise "This platform is not supported (#{RUBY_PLATFORM})"
-  end
-
-  # "before all"
-  browser = Browser.new
-end
-
-Before do
-  @browser = browser
-end
-
-# "after all"
-at_exit do
-  browser.close
-end

data/examples/watir/features/support/screenshots.rb

@@ -1,47 +0,0 @@
-# This is an example of how you can set up screenshots for your
-# browser testing. Just run cucumber with --format html --out report.html
-#
-# The code below will work on OS X or Windows (with IE Watir only).
-# Adding support for other platforms should be easy - as long as there is a
-# ruby library or command line tool to take pictures.
-#
-module Screenshots
-  if Cucumber::OS_X
-    def embed_screenshot(id)
-      `screencapture -t png #{id}.png`
-      embed("#{id}.png", 'image/png')
-    end
-  elsif Cucumber::WINDOWS
-    # http://wtr.rubyforge.org/rdoc/classes/Watir/ScreenCapture.html
-    require 'watir/screen_capture'
-    include Watir::ScreenCapture
-    def embed_screenshot(id)
-      screen_capture("#{id}.jpg", true)
-      embed("#{id}.jpg", 'image/jpeg')
-    end
-  else
-    # Other platforms...
-    def embed_screenshot(_id)
-      STDERR.puts 'Sorry - no screenshots on your platform yet.'
-    end
-  end
-end
-World(Screenshots)
-
-After do
-  embed_screenshot("screenshot-#{Time.new.to_i}")
-end
-
-# Other variants:
-#
-# Only take screenshot on failures
-#
-#   After do |scenario|
-#     embed_screenshot("screenshot-#{Time.new.to_i}") if scenario.failed?
-#   end
-#
-# Only take screenshot for scenarios or features tagged @screenshot
-#
-#   After(@screenshot) do
-#     embed_screenshot("screenshot-#{Time.new.to_i}")
-#   end

data/features/docs/api/list_step_defs_as_json.feature

@@ -1,64 +0,0 @@
-@spawn
-Feature: List step defs as json
-
-  In order to build tools on top of Cucumber
-  As a tool developer
-  I want to be able to query a features directory for all the step definitions it contains
-
-  Background:
-    Given a directory named "features"
-
-  @todo-windows
-  Scenario: Two Ruby step definitions, in the same file
-    Given a file named "features/step_definitions/steps.rb" with:
-      """
-      Given(/foo/i)  { }
-      Given(/b.r/xm) { }
-      """
-    When I run the following Ruby code:
-      """
-      require 'cucumber'
-      puts Cucumber::StepDefinitions.new.to_json
-
-      """
-    Then it should pass with JSON:
-      """
-      [
-        {
-          "source": {"expression": "foo", "type": "regular expression"},
-          "regexp": {"source": "foo", "flags": "i"}
-        },
-        {
-          "source": {"expression": "b.r", "type": "regular expression"},
-          "regexp": {"source": "b.r", "flags": "mx"}
-        }
-      ]
-      """
-
-  @todo-windows
-  Scenario: Non-default directory structure
-    Given a file named "my_weird/place/steps.rb" with:
-      """
-      Given(/foo/)  { }
-      Given(/b.r/x) { }
-      """
-    When I run the following Ruby code:
-      """
-      require 'cucumber'
-      puts Cucumber::StepDefinitions.new(:autoload_code_paths => ['my_weird']).to_json
-
-      """
-    Then it should pass with JSON:
-      """
-      [
-        {
-          "source": {"expression": "foo", "type": "regular expression"},
-          "regexp": {"source": "foo", "flags": ""}
-        },
-        {
-          "source": {"expression": "b.r", "type": "regular expression"},
-          "regexp": {"source": "b.r", "flags": "x"}
-        }
-      ]
-
-      """

data/features/docs/api/listen_for_events.feature

@@ -1,59 +0,0 @@
-Feature: Listen for events
-
-  Cucumber's `config` object has an event bus that you can use to listen for
-  various events that happen during your test run.
-
-  Scenario: Step Matched Event
-    Given a file named "features/test.feature" with:
-      """
-      Feature:
-        Scenario:
-          Given matching
-      """
-    And a file named "features/step_definitions/steps.rb" with:
-      """
-      Given(/matching/) do
-      end
-      """
-    And a file named "features/support/my_listener.rb" with:
-      """
-      AfterConfiguration do |config|
-        io = config.out_stream
-        config.on_event :step_activated do |event|
-          io.puts "Success!"
-          io.puts "Step name:       #{event.test_step.name}"
-          io.puts "Source location: #{event.step_match.location}"
-        end
-      end
-      """
-    When I run `cucumber`
-    Then it should pass with:
-      """
-      Success!
-      Step name:       matching
-      Source location: features/step_definitions/steps.rb:1
-      """
-
-  Scenario: After Test Step event
-    Given a file named "features/test.feature" with:
-      """
-      Feature:
-        Scenario:
-          Given passing
-      """
-    And the standard step definitions
-    And a file named "features/support/my_listener.rb" with:
-      """
-      AfterConfiguration do |config|
-        io = config.out_stream
-        config.on_event :test_step_finished do |event|
-          io.puts event.result.passed?
-        end
-      end
-      """
-    When I run `cucumber`
-    Then it should pass with:
-      """
-      true
-      """
-

data/features/docs/api/run_cli_main_with_existing_runtime.feature

@@ -1,27 +0,0 @@
-@spawn
-Feature: Run Cli::Main with existing Runtime
-
-  This is the API that Spork uses. It creates an existing runtime.
-  When the process forks, Spork them passes the runtime to Cli::Main to
-  run it.
-
-    @todo-windows
-    Scenario: Run a single feature
-      Given the standard step definitions
-      Given a file named "features/success.feature" with:
-        """
-        Feature:
-          Scenario:
-            Given this step passes
-        """
-      When I run the following Ruby code:
-        """
-        require 'cucumber'
-        runtime = Cucumber::Runtime.new
-        Cucumber::Cli::Main.new([]).execute!(runtime)
-        """
-      Then it should pass
-      And the output should contain:
-        """
-        Given this step passes
-        """

data/features/docs/cli/backtraces.feature

@@ -1,36 +0,0 @@
-Feature: Backtraces
-
-  In order to discover errors quickly
-  As a cuker
-  I want to see backtraces for failures
-
-  Background:
-    Given a file named "features/failing_hard.feature" with:
-      """
-      Feature: Sample
-        Scenario: Example
-          Given failing
-      """
-
-  @jruby
-  Scenario: Backtraces enabled
-    Given a file named "features/step_definitions/steps.rb" with:
-      """
-      require 'java'
-      java_import 'java.util.Collections'
-
-      Given /^failing$/ do
-        Collections.empty_list.add 1
-      end
-      """
-    When I run `cucumber features/failing_hard.feature`
-    Then it should fail with:
-      """
-      Feature: Sample
-
-        Scenario: Example # features/failing_hard.feature:2
-          Given failing   # features/step_definitions/steps.rb:4
-             (Java::JavaLang::UnsupportedOperationException)
-            java.util.AbstractList.add(java/util/AbstractList.java:
-      """
-

data/features/docs/cli/dry_run.feature

@@ -1,73 +0,0 @@
-Feature: Dry Run
-
-  Dry run gives you a way to quickly scan your features without actually running them.
-
-  - Invokes formatters without executing the steps.
-  - This also omits the loading of your support/env.rb file if it exists.
-
-  Scenario: With a failing step
-    Given a file named "features/test.feature" with:
-      """
-      Feature: test
-        Scenario:
-          Given this step fails
-      """
-    And the standard step definitions
-    When I run `cucumber --dry-run`
-    Then it should pass with exactly:
-      """
-      Feature: test
-
-        Scenario:               # features/test.feature:2
-          Given this step fails # features/step_definitions/steps.rb:4
-
-      1 scenario (1 skipped)
-      1 step (1 skipped)
-
-      """
-
-  Scenario: In strict mode
-    Given a file named "features/test.feature" with:
-      """
-      Feature: test
-        Scenario:
-          Given this step fails
-      """
-    And the standard step definitions
-    When I run `cucumber --dry-run --strict`
-    Then it should pass with exactly:
-      """
-      Feature: test
-
-        Scenario:               # features/test.feature:2
-          Given this step fails # features/step_definitions/steps.rb:4
-
-      1 scenario (1 skipped)
-      1 step (1 skipped)
-
-      """
-
-  Scenario: In strict mode with an undefined step
-    Given a file named "features/test.feature" with:
-      """
-      Feature: test
-        Scenario:
-          Given this step is undefined
-      """
-    When I run `cucumber --dry-run --strict`
-    Then it should fail with:
-      """
-      Feature: test
-
-        Scenario:                      # features/test.feature:2
-          Given this step is undefined # features/test.feature:3
-            Undefined step: "this step is undefined" (Cucumber::Undefined)
-            features/test.feature:3:in `Given this step is undefined'
-
-      Undefined Scenarios:
-      cucumber features/test.feature:2 # Scenario: 
-
-      1 scenario (1 undefined)
-      1 step (1 undefined)
-
-      """

data/features/docs/cli/exclude_files.feature

@@ -1,18 +0,0 @@
-Feature: Excluding ruby and feature files from runs
-
-  Developers are able to easily exclude files from cucumber runs
-  This is a nice feature to have in conjunction with profiles, so you can exclude
-  certain environment files from certain runs.
-
-  Scenario: exclude ruby files
-    Given an empty file named "features/support/dont_require_me.rb"
-    And an empty file named "features/step_definitions/fooz.rb"
-    And an empty file named "features/step_definitions/foof.rb"
-    And an empty file named "features/step_definitions/foot.rb"
-    And an empty file named "features/support/require_me.rb"
-    When I run `cucumber features -q --verbose --exclude features/support/dont --exclude foo[zf]`
-    Then "features/support/require_me.rb" should be required
-    And "features/step_definitions/foot.rb" should be required
-    And "features/support/dont_require_me.rb" should not be required
-    And "features/step_definitions/foof.rb" should not be required
-    And "features/step_definitions/fooz.rb" should not be required

data/features/docs/cli/execute_with_tag_filter.feature

@@ -1,117 +0,0 @@
-Feature: Tag logic
-  In order to conveniently run subsets of features
-  As a Cuker
-  I want to select features using logical AND/OR of tags
-
-  Background:
-    Given a file named "features/test.feature" with:
-      """
-      @feature
-      Feature: Sample
-
-        @one @three
-        Scenario: Example
-          Given passing
-
-        @one
-        Scenario: Another Example
-          Given passing
-
-        @three
-        Scenario: Yet another Example
-          Given passing
-
-        @ignore
-        Scenario: And yet another Example
-      """
-
-  Scenario: ANDing tags
-    When I run `cucumber -q -t '@one and @three' features/test.feature`
-    Then it should pass with:
-      """
-      @feature
-      Feature: Sample
-
-        @one @three
-        Scenario: Example
-          Given passing
-
-      1 scenario (1 undefined)
-      1 step (1 undefined)
-
-      """
-
-  Scenario: ORing tags
-    When I run `cucumber -q -t '@one or @three' features/test.feature`
-    Then it should pass with:
-      """
-      @feature
-      Feature: Sample
-
-        @one @three
-        Scenario: Example
-          Given passing
-
-        @one
-        Scenario: Another Example
-          Given passing
-
-        @three
-        Scenario: Yet another Example
-          Given passing
-
-      3 scenarios (3 undefined)
-      3 steps (3 undefined)
-
-      """
-
-  Scenario: Negative tags
-    When I run `cucumber -q -t 'not @three' features/test.feature`
-    Then it should pass with:
-      """
-      @feature
-      Feature: Sample
-
-        @one
-        Scenario: Another Example
-          Given passing
-
-        @ignore
-        Scenario: And yet another Example
-
-      2 scenarios (1 undefined, 1 passed)
-      1 step (1 undefined)
-      """
-
-  Scenario: Run with limited tag count, blowing it on scenario
-     When I run `cucumber -q --no-source --tags @one:1 features/test.feature`
-     Then it fails before running features with:
-       """
-       @one occurred 2 times, but the limit was set to 1
-         features/test.feature:5
-         features/test.feature:9
-       """
-
-  Scenario: Run with limited tag count, blowing it via feature inheritance
-     When I run `cucumber -q --no-source --tags @feature:1 features/test.feature`
-     Then it fails before running features with:
-       """
-       @feature occurred 4 times, but the limit was set to 1
-         features/test.feature:5
-         features/test.feature:9
-         features/test.feature:13
-         features/test.feature:17
-       """
-
-  Scenario: Run with limited tag count using negative tag, blowing it via a tag that is not run
-     When I run `cucumber -q --no-source --tags 'not @one:1' features/test.feature`
-     Then it fails before running features with:
-       """
-       @one occurred 2 times, but the limit was set to 1
-       """
-
-  Scenario: Limiting with tags which do not exist in the features
-    Originally added to check [Lighthouse bug #464](https://rspec.lighthouseapp.com/projects/16211/tickets/464).
-
-    When I run `cucumber -q -t @i_dont_exist features/test.feature`
-    Then it should pass