hubbub 0.0.6

data/lib/vendor/plugins/rspec/Upgrade.rdoc

@@ -0,0 +1,199 @@
+= Upgrade to rspec-1.2.9
+
+== What's new
+
+=== spec/spec.opts
+
+If you have a spec/spec.opts file, the spec command will now use that
+automatically as long as you don't include any options on the command line.
+
+=== let()
+
+Writing specs tends to follow a regular pattern of using local variables, discovering duplication, and then having to convert to local variables to instance variables by adding an "@" symbol. The let() method assigns the result of a lazy eval'd block as the return value of an instance method using
+the same name. This way you can go from this:
+
+    describe Subscription do
+      it "does something" do
+        subscription = Subscription.create :limit => 1
+        subscription...
+      end
+
+      it "does something else" do
+        subscription = Subscription.create :limit => 1
+        subscription...
+      end
+    end
+
+to this:
+
+    describe Subscription do
+      let(:subscription) { Subscription.create :limit => 1 }
+
+      it "does something" do
+        subscription...
+      end
+
+      it "does something else" do
+        subscription...
+      end
+    end
+
+=== its()
+
+If you're in the habit of writing one-liners using implicit subject, this new
+its() feature is for you. Here's the basic idea:
+
+    describe Array do
+      its(:length) { should == 0 }
+    end
+
+= Upgrade to rspec-1.2.3-1.2.7
+
+== What's Changed
+
+=== Matcher DSL
+
+Use Spec::Matchers.define instead of Spec::Matchers.create (which is now
+deprecated).
+
+=== Explicit Predicate Matchers are deprecated
+
+With the addition of the new Matcher DSL the old, confusing, and
+almost-nobody-uses-it explicit predicate matcher functionality's days are now
+numbered.
+
+If you're not familiar with this feature, don't worry about it. If you have anything
+that looks like this:
+
+    predicate_matchers[:swim] = :can_swim?
+
+Or this
+
+    config.predicate_matchers[:swim] = :can_swim?
+
+Change it to this:
+
+    Spec::Matchers.define :swim do
+      match do |potential_swimmer|
+        potential_swimmer.can_swim?
+      end
+    end
+
+== Custom Formatters
+
+If you have an custom formatter, the <tt>add_example_group</tt> method has
+been changed to <tt>example_group_started</tt>, and kept as an alias so your
+formatters will still work. Though not yet, <tt>add_example_group</tt> will be
+deprecated in a future minor release, and removed in a future major release,
+so we recommend you make this change now.
+
+= Upgrade to rspec-1.2.2
+
+== What's Changed
+
+=== <tt>require 'rubygems' unless ENV['NO_RUBYGEMS']</tt>
+
+After minor public outcry and confusion, we restored necessary references to
+rubygems in rspec. If you use a different mechanism for managing gems, just
+set a <tt>NO_RUBYGEMS</tt> environment variable (to any non-nil value).
+
+=== Proxies and locations
+
+This is probably only interesting to you if you use custom formatters.
+
+Formatters now receive Spec::Example::ExampleGroupProxy and
+Spec::Example::ExampleGroup objects with cohesive APIs for reporting. See the
+RDoc for those classes and Spec::Runner::Formatter::BaseFormatter for more
+information.
+
+== What's new
+
+=== The new matcher DSL works with test/unit (without the rest of rspec)
+
+We'll be separating this out to its own gem for rspec 2.0, but for now, just install
+rspec >= 1.2.1 and add the following to your <tt>test_helper</tt> file:
+
+    require 'spec/expectations'
+    class Test::Unit::TestCase
+      include Spec::Matchers
+    end
+
+This will add <tt>should()</tt> and <tt>should_not()</tt> to your objects, make all of
+rspec's built-in matchers available to your tests, INCLUDING rspec's DSL for
+creating matchers (see below, under Upgrade to rspec-1.2.0)
+
+=== debugger
+
+If you have ruby-debug installed, you can set a breakpoint by adding <tt>debugger()</tt>
+in your code:
+
+    # some code .....
+    debugger
+    # some more code ....
+
+... and using the <tt>--debugger</tt> or <tt>-u</tt> command line option.
+
+    spec path/to/file.rb --debugger
+
+= Upgrade to rspec-1.2.0
+
+== What's Changed
+
+=== WARNINGS
+
+* If you use the ruby command to run specs instead of the spec command, you'll
+  need to require 'spec/autorun' or they won't run. This won't affect you if
+  you use the spec command or the Spec::Rake::SpecTask that ships with RSpec.
+
+* require 'spec/test/unit' to invoke test/unit interop if you're using
+  RSpec's core (this is handled implicitly with spec-rails)
+
+* setup and teardown are gone - use before and after instead
+
+  * you can still use setup and teardown if you're using
+    Test::Unit::TestCase as the base ExampleGroup class (which is implicit
+    in rspec-rails)
+
+* The matcher protocol has been improved. The old protocol is still supported,
+  but we added support for two new methods that speak a bit more clearly:
+
+    failure_message          => failure_message_for_should
+    negative_failure_message => failure_message_for_should_not
+
+* All references to rubygems have been removed from within rspec's code.
+
+  * See http://gist.github.com/54177 for rationale and suggestions on
+    alternative approaches to loading rubygems
+
+== What's New
+
+=== Ruby 1.9
+
+RSpec now works with Ruby 1.9.1. See http://wiki.github.com/dchelimsky/rspec/ruby-191
+for useful information.
+
+=== Improved heckle integration
+
+RSpec works with heckle again! Gotta use heckle >= 1.4.2 for this to work
+though, and it only works with ruby-1.8.6 and 1.8.7 (heckle doesn't support
+1.9.1 yet).
+
+    [sudo] gem install heckle --version ">=1.4.2"
+    spec spec/game/mastermind.rb --heckle Game::Mastermind
+
+=== New Matcher DSL
+
+We've added a new DSL for generating custom matchers very simply and cleanly.
+We'll still support the simple_matcher method, so never fear if you're using
+that, but we recommend that you start developing your new matchers with this
+new syntax.
+
+    Spec::Matchers.create :be_a_multiple_of do |smaller|
+      match do |bigger|
+        bigger % smaller == 0
+      end
+    end
+
+    9.should be_a_multiple_of(3)
+
+See <tt>features/matchers/define_matcher.feature</tt> for more examples

data/lib/vendor/plugins/rspec/cucumber.yml

@@ -0,0 +1,5 @@
+default: --require features features -t ~@wip
+pending: --require features features-pending
+no_heckle: --require features features --exclude heckle
+focus: --require features features -t focus
+wip: --require features features -t @wip

data/lib/vendor/plugins/rspec/features/before_and_after_blocks/before_and_after_blocks.feature

@@ -0,0 +1,167 @@
+Feature: before and after blocks
+
+  As a developer using RSpec
+  I want to execute arbitrary code before and after each example
+  So that I can control the environment in which it is run
+
+    This is supported by the before and after methods which each take a symbol
+    indicating the scope, and a block of code to execute.
+
+    before(:each) blocks are run before each example
+    before(:all) blocks are run once before all of the examples in a group
+    before(:suite) blocks are run once before the entire suite
+
+    after(:each) blocks are run after each example
+    after(:all) blocks are run once after all of the examples in a group
+    after(:suite) blocks are run once after the entire suite
+
+    Before and after blocks are called in the following order:
+      before suite
+      before all
+      before each
+      after each
+      after all
+      after suite
+
+    Before and after blocks can be defined in the example groups to which they
+    apply or in a configuration. When defined in a configuration, they can be
+    applied to all groups or subsets of all groups defined by example group
+    types.
+
+  Scenario: define before(:each) block in example group
+    Given a file named "before_each_in_example_group_spec.rb" with:
+      """
+      class Thing
+        def widgets
+          @widgets ||= []
+        end
+      end
+
+      describe Thing do
+        before(:each) do
+          @thing = Thing.new
+        end
+
+        context "initialized in before(:each)" do
+          it "has 0 widgets" do
+            @thing.should have(0).widgets
+          end
+
+          it "can get accept new widgets" do
+            @thing.widgets << Object.new
+          end
+
+          it "does not share state across examples" do
+            @thing.should have(0).widgets
+          end
+        end
+      end
+      """
+    When I run "spec before_each_in_example_group_spec.rb"
+    Then the stdout should include "3 examples, 0 failures"
+
+  Scenario: define before(:all) block in example group
+    Given a file named "before_all_in_example_group_spec.rb" with:
+      """
+      class Thing
+        def widgets
+          @widgets ||= []
+        end
+      end
+
+      describe Thing do
+        before(:all) do
+          @thing = Thing.new
+        end
+
+        context "initialized in before(:all)" do
+          it "has 0 widgets" do
+            @thing.should have(0).widgets
+          end
+
+          it "can get accept new widgets" do
+            @thing.widgets << Object.new
+          end
+
+          it "shares state across examples" do
+            @thing.should have(1).widgets
+          end
+        end
+      end
+      """
+    When I run "spec before_all_in_example_group_spec.rb"
+    Then the stdout should include "3 examples, 0 failures"
+
+  Scenario: define before and after blocks in configuration
+    Given a file named "befores_in_configuration_spec.rb" with:
+      """
+      Spec::Runner.configure do |config|
+        config.before(:suite) do
+          $before_suite = "before suite"
+        end
+        config.before(:each) do
+          @before_each = "before each"
+        end
+        config.before(:all) do
+          @before_all = "before all"
+        end
+      end
+
+      describe "stuff in before blocks" do
+        describe "with :suite" do
+          it "should be available in the example" do
+            $before_suite.should == "before suite"
+          end
+        end
+        describe "with :all" do
+          it "should be available in the example" do
+            @before_all.should == "before all"
+          end
+        end
+        describe "with :each" do
+          it "should be available in the example" do
+            @before_each.should == "before each"
+          end
+        end
+      end
+      """
+    When I run "spec befores_in_configuration_spec.rb"
+    Then the stdout should include "3 examples, 0 failures"
+
+  Scenario: before/after blocks are run in order
+    Given a file named "ensure_block_order_spec.rb" with:
+      """
+      Spec::Runner.configure do |config|
+        config.before(:suite) do
+          puts "before suite"
+        end
+        config.after(:suite) do
+          puts "after suite"
+        end
+      end
+
+      describe "before and after callbacks" do
+        before(:all) do
+          puts "before all"
+        end
+
+        before(:each) do
+          puts "before each"
+        end
+
+        after(:each) do
+          puts "after each"
+        end
+
+        after(:all) do
+          puts "after all"
+        end
+
+        it "gets run in order" do
+
+        end
+      end
+      """
+    When I run "spec ensure_block_order_spec.rb"
+    Then the stdout should include /before suite\nbefore all\nbefore each\nafter each\n\.after all\n.*after suite/m
+

data/lib/vendor/plugins/rspec/features/command_line/line_number_option.feature

@@ -0,0 +1,56 @@
+Feature: Spec and test together
+
+  As an RSpec user
+  I want to run one example identified by the line number
+  
+  Background:
+    Given a file named "example.rb" with:
+      """
+      describe "a group" do
+
+        it "has a first example" do
+
+        end
+        
+        it "has a second example" do
+
+        end
+        
+      end
+      """
+
+  Scenario: two examples - first example on declaration line
+    When I run "spec example.rb:3 --format nested"
+    Then the stdout should include "1 example, 0 failures"
+    And the stdout should include "has a first example"
+    But the stdout should not match "has a second example"
+
+  Scenario: two examples - first example from line inside declaration
+    When I run "spec example.rb:4 --format nested"
+    Then the stdout should include "1 example, 0 failures"
+    And the stdout should include "has a first example"
+    But the stdout should not match "has a second example"
+
+  Scenario: two examples - first example from line below declaration
+    When I run "spec example.rb:6 --format nested"
+    Then the stdout should include "1 example, 0 failures"
+    And the stdout should include "has a first example"
+    But the stdout should not match "has a second example"
+
+  Scenario: two examples - second example from line below declaration
+    When I run "spec example.rb:7 --format nested"
+    Then the stdout should include "1 example, 0 failures"
+    And the stdout should include "has a second example"
+    But the stdout should not match "has a first example"
+
+  Scenario: two examples - both examples from the group declaration
+    When I run "spec example.rb:1 --format nested"
+    Then the stdout should include "2 examples, 0 failures"
+    And the stdout should include "has a second example"
+    And the stdout should include "has a first example"
+
+  Scenario: two examples - both examples from above the first example declaration
+    When I run "spec example.rb:2 --format nested"
+    Then the stdout should include "2 examples, 0 failures"
+    And the stdout should include "has a second example"
+    And the stdout should include "has a first example"

data/lib/vendor/plugins/rspec/features/command_line/line_number_option_with_example_with_no_name.feature

@@ -0,0 +1,22 @@
+Feature: Spec and test together
+
+  As an RSpec user
+  I want to run one example identified by the line number
+  
+  Background:
+    Given a file named "example.rb" with:
+      """
+      describe 9 do
+
+        it { should be > 8 }
+
+        it { should be < 10 }
+        
+      end
+      """
+
+  Scenario: two examples - first example on declaration line
+    When I run "spec example.rb:3 --format nested"
+    Then the stdout should include "1 example, 0 failures"
+    Then the stdout should include "should be > 8"
+    But the stdout should not match "should be < 10"

data/lib/vendor/plugins/rspec/features/example_groups/define_example_attribute.feature

@@ -0,0 +1,41 @@
+Feature: Define example attribute
+
+  In order to streamline process
+  As an RSpec user
+  I want to easily define helper methods that act as a variable assignment
+  
+  It is fairly common to start with a local variable in one example, use the same
+  local variable in the next, and then extract the declaration of that variable
+  to before(:each). This requires converting the locals to instance variables.
+  
+  This feature streamlines the process by defining a helper method so you can extract
+  the duplication without having to change other references to the same variables
+  to @instance_variables.
+
+  Scenario: 
+    Given a file named "counter_spec.rb" with:
+    """
+    require 'spec/autorun'
+    
+    class Counter
+      def initialize
+        @count = 0
+      end
+      def count
+        @count += 1
+      end
+    end
+
+    describe Counter do
+      let(:counter) { Counter.new }
+      it "returns 1 the first time" do
+        counter.count.should == 1
+      end
+      it "returns 2 the second time because the counter itself is cached by the 'assign' method" do
+        counter.count
+        counter.count.should == 2
+      end
+    end
+    """
+    When I run "spec counter_spec.rb"
+    Then the stdout should include "2 examples, 0 failures"

data/lib/vendor/plugins/rspec/features/example_groups/example_group_with_should_methods.feature

@@ -0,0 +1,29 @@
+Feature: Spec::ExampleGroup with should methods
+
+  As an RSpec adopter accustomed to classes and methods
+  I want to use should_* methods in an ExampleGroup
+  So that I use RSpec with classes and methods that look more like RSpec examples
+
+  Scenario Outline: Example Group class with should methods
+    Given a file named "example_group_with_should_methods.rb" with:
+    """
+    require 'spec/autorun'
+
+    class MySpec < Spec::ExampleGroup
+      def should_pass_with_should
+        1.should == 1
+      end
+
+      def should_fail_with_should
+        1.should == 2
+      end
+    end
+    """
+    When I run "<Command> example_group_with_should_methods.rb"
+    Then the exit code should be 256
+    And the stdout should include "2 examples, 1 failure"
+
+  Scenarios: Run with ruby and spec
+    | Command |
+    | ruby    |
+    | spec    |

data/lib/vendor/plugins/rspec/features/example_groups/implicit_docstrings.feature

@@ -0,0 +1,59 @@
+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 Outline: run passing examples
+    Given a file named "implicit_docstrings_example.rb" with:
+    """
+    require 'spec/autorun'
+    describe "Examples with no docstrings generate their own:" do
+
+      specify { 3.should be < 5 }
+
+      specify { ["a"].should include("a") }
+
+      specify { [1,2,3].should respond_to(:size) }
+
+    end
+    """
+
+    When I run "<Command> implicit_docstrings_example.rb -fs"
+
+    Then the stdout should include /should be < 5/
+    And the stdout should include /should include "a"/
+    And the stdout should include /should respond to #size/
+
+  Scenarios: Run with ruby and spec
+    | Command |
+    | ruby    |
+    | spec    |
+
+  Scenario Outline: run failing examples
+    Given a file named "failing_implicit_docstrings_example.rb" with:
+    """
+    require 'spec/autorun'
+    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 { ["a"].should include("b") }
+
+      it { [1,2,3].should_not respond_to(:size) }
+
+    end
+    """
+
+    When I run "<Command> failing_implicit_docstrings_example.rb -fs"
+
+    Then the stdout should include /should equal 2/
+    And the stdout should include /should be > 5/
+    And the stdout should include /should include "b"/
+    And the stdout should include /should not respond to #size/

data/lib/vendor/plugins/rspec/features/example_groups/nested_groups.feature

@@ -0,0 +1,32 @@
+Feature: Nested example groups
+
+  As an RSpec user
+  I want to nest examples groups
+  So that I can better organize my examples
+
+  Scenario Outline: Nested example groups
+    Given a file named "nested_example_groups.rb" with:
+    """
+    require 'spec/autorun'
+
+    describe "Some Object" do
+      describe "with some more context" do
+        it "should do this" do
+          true.should be_true
+        end
+      end
+      describe "with some other context" do
+        it "should do that" do
+          false.should be_false
+        end
+      end
+    end
+    """
+    When I run "<Command> nested_example_groups.rb -fs"
+    Then the stdout should include /Some Object with some more context/
+    And the stdout should include /Some Object with some other context/
+
+  Scenarios: Run with ruby and spec
+    | Command |
+    | ruby    |
+    | spec    |

data/lib/vendor/plugins/rspec/features/expectations/customized_message.feature

@@ -0,0 +1,54 @@
+Feature: customized message
+
+  In order to get the feedback I want
+  As an RSpec user
+  I want to customize the failure message per example
+  
+  Scenario: one additional method
+    Given a file named "node_spec.rb.rb" with:
+      """
+      class Node
+        def initialize(state=:waiting)
+          @state = state
+        end
+        def state
+          @state
+        end
+        def waiting?
+          @state == :waiting
+        end
+        def started?
+          @state == :started
+        end
+        def start
+          @state = :started
+        end
+      end
+      
+      describe "a new Node" do
+        it "should be waiting" do
+          node = Node.new(:started) #start w/ started to trigger failure
+          node.should be_waiting, "node.state: #{node.state} (first example)"
+        end
+        
+        it "should not be started" do
+          node = Node.new(:started) #start w/ started to trigger failure
+          node.should_not be_started, "node.state: #{node.state} (second example)"
+        end
+      end
+      
+      describe "node.start" do
+        it "should change the state" do
+          node = Node.new(:started) #start w/ started to trigger failure
+          lambda {node.start}.should change{node.state}, "expected a change"
+        end
+      end
+      
+      """
+    When I run "spec node_spec.rb.rb --format specdoc"
+    Then the stdout should include "3 examples, 3 failures"
+    And  the stdout should not match "to return true, got false"
+    And  the stdout should not match "to return false, got true"
+    And  the stdout should include "node.state: started (first example)"
+    And  the stdout should include "node.state: started (second example)"
+    And  the stdout should include "expected a change"