syllable_counter 0.0.1 → 1.0.0

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/custom_matchers/define_matcher_outside_rspec.feature

@@ -0,0 +1,38 @@
+Feature: define matcher outside rspec
+
+  In order to express my domain clearly in my code examples
+  As a non-rspec user
+  I want a shortcut to define custom matchers
+
+  Scenario: define a matcher with default messages
+    Given a file named "test_multiples.rb" with:
+      """ruby
+      require "rspec/expectations"
+      require "test/unit"
+
+      RSpec::Matchers.define :be_a_multiple_of do |expected|
+        match do |actual|
+          actual % expected == 0
+        end
+      end
+
+      class Test::Unit::TestCase
+        include RSpec::Matchers
+      end
+
+      class TestMultiples < Test::Unit::TestCase
+
+        def test_9_should_be_a_multiple_of_3
+          9.should be_a_multiple_of(3)
+        end
+
+        def test_9_should_be_a_multiple_of_4
+          9.should be_a_multiple_of(4)
+        end
+
+      end
+      """
+    When I run `ruby test_multiples.rb`
+    Then the exit status should not be 0
+    And the output should contain "expected 9 to be a multiple of 4"
+    And the output should contain "2 tests, 0 assertions, 0 failures, 1 errors"

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/custom_matchers/define_matcher_with_fluent_interface.feature

@@ -0,0 +1,24 @@
+Feature: define matcher with fluent interface
+
+  Use the chain() method to define matchers with a fluent interface.
+
+  Scenario: chained method with argumetn
+    Given a file named "between_spec.rb" with:
+      """ruby
+      RSpec::Matchers.define :be_bigger_than do |first|
+        match do |actual|
+          (actual > first) && (actual < @second)
+        end
+
+        chain :but_smaller_than do |second|
+          @second = second
+        end
+      end
+
+      describe 5 do
+        it { should be_bigger_than(4).but_smaller_than(6) }
+      end
+      """
+    When I run `rspec between_spec.rb --format documentation`
+    Then the output should contain "1 example, 0 failures"
+    And  the output should contain "should be bigger than 4"

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/customized_message.feature

@@ -0,0 +1,22 @@
+Feature: customized message
+
+  RSpec tries to provide useful failure messages, but for cases in which you
+  want more specific information, you can define your own message right in the
+  example. This works for any matcher _other than the operator matchers_.
+
+  Scenario: customize failure message
+    Given a file named "example_spec.rb" with:
+      """ruby
+      describe Array do
+        context "when created with `new`" do
+          it "is empty" do
+            array = Array.new
+            array << 1 # trigger a failure to demonstrate the message
+            array.should be_empty, "expected empty array, got #{array.inspect}"
+          end
+        end
+      end
+
+      """
+    When I run `rspec example_spec.rb --format documentation`
+    Then the output should contain "expected empty array, got [1]"

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/diffing.feature

@@ -0,0 +1,85 @@
+Feature: diffing
+
+  When appropriate, failure messages will automatically include a diff.
+
+  Scenario: diff for a multiline string
+    Given a file named "example_spec.rb" with:
+      """ruby
+      describe "a multiline string" do
+        it "is like another string" do
+          expected = <<-EXPECTED
+      this is the
+        expected
+          string
+      EXPECTED
+          actual = <<-ACTUAL
+      this is the
+        actual
+          string
+      ACTUAL
+          actual.should eq(expected)
+        end
+      end
+      """
+    When I run `rspec example_spec.rb`
+    Then the output should contain:
+      """
+             Diff:
+             @@ -1,4 +1,4 @@
+              this is the
+             -  expected
+             +  actual
+                  string
+      """
+
+  Scenario: diff for a multiline string and a regexp
+    Given a file named "example_spec.rb" with:
+      """ruby
+      describe "a multiline string" do
+        it "is like another string" do
+          expected = /expected/m
+          actual = <<-ACTUAL
+      this is the
+        actual
+          string
+      ACTUAL
+          actual.should =~ expected
+        end
+      end
+      """
+    When I run `rspec example_spec.rb`
+    Then the output should contain:
+      """
+             Diff:
+             @@ -1,2 +1,4 @@
+             -/expected/m
+             +this is the
+             +  actual
+             +    string
+      """
+
+  Scenario: no diff for a single line strings
+    Given a file named "example_spec.rb" with:
+      """ruby
+      describe "a single line string" do
+        it "is like another string" do
+          expected = "this string"
+          actual   = "that string"
+          actual.should eq(expected)
+        end
+      end
+      """
+    When I run `rspec example_spec.rb`
+    Then the output should not contain "Diff:"
+
+  Scenario: no diff for numbers
+    Given a file named "example_spec.rb" with:
+      """ruby
+      describe "a number" do
+        it "is like another number" do
+          1.should eq(2)
+        end
+      end
+      """
+    When I run `rspec example_spec.rb`
+    Then the output should not contain "Diff:"

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/implicit_docstrings.feature

@@ -0,0 +1,52 @@
+Feature: implicit docstrings
+
+  As an RSpec user
+  I want examples to generate their own names
+  So that I can reduce duplication between example names and example code
+
+  Scenario: run passing examples
+    Given a file named "implicit_docstrings_spec.rb" with:
+    """ruby
+    describe "Examples with no docstrings generate their own:" do
+
+      specify { 3.should be < 5 }
+
+      specify { [1,2,3].should include(2) }
+
+      specify { [1,2,3].should respond_to(:size) }
+
+    end
+    """
+
+    When I run `rspec ./implicit_docstrings_spec.rb -fdoc`
+
+    Then the output should contain "should be < 5"
+    And the output should contain "should include 2"
+    And the output should contain "should respond to #size"
+
+  Scenario: run failing examples
+    Given a file named "failing_implicit_docstrings_spec.rb" with:
+    """ruby
+    describe "Failing examples with no descriptions" do
+
+      # description is auto-generated as "should equal(5)" based on the last #should
+      it do
+        3.should equal(2)
+        5.should equal(5)
+      end
+
+      it { 3.should be > 5 }
+
+      it { [1,2,3].should include(4) }
+
+      it { [1,2,3].should_not respond_to(:size) }
+
+    end
+    """
+
+    When I run `rspec ./failing_implicit_docstrings_spec.rb -fdoc`
+
+    Then the output should contain "should equal 2"
+    And the output should contain "should be > 5"
+    And the output should contain "should include 4"
+    And the output should contain "should not respond to #size"

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/step_definitions/additional_cli_steps.rb

@@ -0,0 +1,22 @@
+# Useful for when the output is slightly different on different versions of ruby
+Then /^the output should contain "([^"]*)" or "([^"]*)"$/ do |string1, string2|
+  unless [string1, string2].any? { |s| all_output =~ regexp(s) }
+    fail %Q{Neither "#{string1}" or "#{string2}" were found in:\n#{all_output}}
+  end
+end
+
+Then /^the output should contain all of these:$/ do |table|
+  table.raw.flatten.each do |string|
+    assert_partial_output(string, all_output)
+  end
+end
+
+Then /^the example(?:s)? should(?: all)? pass$/ do
+  step %q{the output should contain "0 failures"}
+  step %q{the exit status should be 0}
+end
+
+Then /^the example should fail$/ do
+  step %q{the output should contain "1 failure"}
+  step %q{the exit status should not be 0}
+end

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/support/env.rb

@@ -0,0 +1,14 @@
+require 'aruba/cucumber'
+
+timeouts = { 'java' => 60 }
+
+Before do
+  @aruba_timeout_seconds = timeouts.fetch(RUBY_PLATFORM) { 15 }
+end
+
+Aruba.configure do |config|
+  config.before_cmd do |cmd|
+    set_env('JRUBY_OPTS', "-X-C #{ENV['JRUBY_OPTS']}") # disable JIT since these processes are so short lived
+  end
+end if RUBY_PLATFORM == 'java'
+

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/support/rubinius.rb

@@ -0,0 +1,6 @@
+# Required until https://github.com/rubinius/rubinius/issues/2430 is resolved
+ENV['RBXOPT'] = "#{ENV["RBXOPT"]} -Xcompiler.no_rbc"
+
+Around "@unsupported-on-rbx" do |scenario, block|
+  block.call unless defined?(Rubinius)
+end

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/syntax_configuration.feature

@@ -0,0 +1,71 @@
+Feature: Syntax Configuration
+
+  In addition to the long-supported `should` syntax, rspec-expectations
+  supports an alternate `expect` syntax. If you want your project to
+  only use one syntax, you can configure the available syntaxes.
+
+  Background:
+    Given a file named "syntaxes_spec.rb" with:
+      """ruby
+      describe "using the should syntax" do
+        specify { 3.should eq(3) }
+        specify { 3.should_not eq(4) }
+        specify { lambda { raise "boom" }.should raise_error("boom") }
+        specify { lambda { }.should_not raise_error }
+      end
+
+      describe "using the expect syntax" do
+        specify { expect(3).to eq(3) }
+        specify { expect(3).not_to eq(4) }
+        specify { expect { raise "boom" }.to raise_error("boom") }
+        specify { expect { }.not_to raise_error }
+      end
+      """
+
+  Scenario: Both syntaxes are available by default
+    When I run `rspec syntaxes_spec.rb`
+    Then the examples should all pass
+
+  Scenario: Disable should syntax
+    Given a file named "disable_should_syntax.rb" with:
+      """ruby
+      RSpec.configure do |config|
+        config.expect_with :rspec do |c|
+          c.syntax = :expect
+        end
+      end
+      """
+    When I run `rspec disable_should_syntax.rb syntaxes_spec.rb`
+    Then the output should contain all of these:
+      | 8 examples, 4 failures    |
+      | undefined method `should' |
+
+  Scenario: Disable expect syntax
+    Given a file named "disable_expect_syntax.rb" with:
+      """ruby
+      RSpec.configure do |config|
+        config.expect_with :rspec do |c|
+          c.syntax = :should
+        end
+        config.mock_with :rspec do |c|
+          c.syntax = :should
+        end
+      end
+      """
+    When I run `rspec disable_expect_syntax.rb syntaxes_spec.rb`
+    Then the output should contain all of these:
+      | 8 examples, 4 failures    |
+      | undefined method `expect' |
+
+  Scenario: Explicitly enable both syntaxes
+    Given a file named "enable_both_syntaxes.rb" with:
+      """ruby
+      RSpec.configure do |config|
+        config.expect_with :rspec do |c|
+          c.syntax = [:should, :expect]
+        end
+      end
+      """
+    When I run `rspec enable_both_syntaxes.rb syntaxes_spec.rb`
+    Then the examples should all pass
+

data/vendor/bundle/gems/rspec-expectations-2.14.2/features/test_frameworks/test_unit.feature

@@ -0,0 +1,44 @@
+Feature: Test::Unit integration
+
+  RSpec-expectations is a stand-alone gem that can be used without the rest of
+  RSpec. If you like the way Test::Unit (or MiniTest) organizes tests, but
+  prefer RSpec's approach to expressing expectations, you can have both.
+
+  The one downside is that failures are reported as errors with MiniTest.
+
+  Scenario: use rspec/expectations with Test::Unit
+    Given a file named "rspec_expectations_test.rb" with:
+      """ruby
+      require 'test/unit'
+      require 'rspec/expectations'
+
+      class RSpecExpectationsTest < Test::Unit::TestCase
+        RSpec::Matchers.define :be_an_integer do
+          match { |actual| Integer === actual }
+        end
+
+        def be_an_int
+          # This is actually an internal rspec-expectations API, but is used
+          # here to demonstrate that deprecation warnings from within
+          # rspec-expectations work correcty without depending on rspec-core
+          RSpec.deprecate(:be_an_int, :replacement => :be_an_integer)
+          be_an_integer
+        end
+
+        def test_passing_expectation
+          expect(1 + 3).to eq 4
+        end
+
+        def test_failing_expectation
+          expect([1,2]).to be_empty
+        end
+
+        def test_custom_matcher_with_deprecation_warning
+          expect(1).to be_an_int
+        end
+      end
+      """
+     When I run `ruby rspec_expectations_test.rb`
+     Then the output should contain "3 tests, 0 assertions, 0 failures, 1 errors" or "3 tests, 0 assertions, 1 failures, 0 errors"
+      And the output should contain "expected empty? to return true, got false"
+      And the output should contain "be_an_int is deprecated"

data/vendor/bundle/gems/rspec-expectations-2.14.2/lib/rspec-expectations.rb

@@ -0,0 +1 @@
+require "rspec/expectations"

data/vendor/bundle/gems/rspec-expectations-2.14.2/lib/rspec/expectations.rb

@@ -0,0 +1,47 @@
+require 'rspec/expectations/extensions'
+require 'rspec/matchers'
+require 'rspec/expectations/expectation_target'
+require 'rspec/matchers/configuration'
+require 'rspec/expectations/fail_with'
+require 'rspec/expectations/errors'
+require 'rspec/expectations/deprecation'
+require 'rspec/expectations/handler'
+require 'rspec/expectations/version'
+require 'rspec/expectations/differ'
+
+module RSpec
+  # RSpec::Expectations adds two instance methods to every object:
+  #
+  #     should(matcher=nil)
+  #     should_not(matcher=nil)
+  #
+  # Both methods take an optional matcher object (See
+  # [RSpec::Matchers](../RSpec/Matchers)).  When `should` is invoked with a
+  # matcher, it turns around and calls `matcher.matches?(self)`.  For example,
+  # in the expression:
+  #
+  #     order.total.should eq(Money.new(5.55, :USD))
+  #
+  # the `should` method invokes the equivalent of `eq.matches?(order.total)`. If
+  # `matches?` returns true, the expectation is met and execution continues. If
+  # `false`, then the spec fails with the message returned by
+  # `eq.failure_message_for_should`.
+  #
+  # Given the expression:
+  #
+  #     order.entries.should_not include(entry)
+  #
+  # the `should_not` method invokes the equivalent of
+  # `include.matches?(order.entries)`, but it interprets `false` as success, and
+  # `true` as a failure, using the message generated by
+  # `eq.failure_message_for_should_not`.
+  #
+  # rspec-expectations ships with a standard set of useful matchers, and writing
+  # your own matchers is quite simple.
+  #
+  # See [RSpec::Matchers](../RSpec/Matchers) for more information about the
+  # built-in matchers that ship with rspec-expectations, and how to write your
+  # own custom matchers.
+  module Expectations
+  end
+end