bitclust-core 0.5.0 → 0.5.1

data/vendor/bundle/ruby/1.9.1/gems/rr-1.0.4/Rakefile

@@ -0,0 +1,88 @@
+require "rake"
+require 'rake/contrib/rubyforgepublisher'
+require 'rake/clean'
+require 'rake/testtask'
+require 'rake/rdoctask'
+
+desc "Runs the Rspec suite"
+task(:default) do
+  run_suite
+end
+
+desc "Runs the Rspec suite"
+task(:spec) do
+  run_suite
+end
+
+def run_suite
+  dir = File.dirname(__FILE__)
+  system("ruby #{dir}/spec/spec_suite.rb") || raise("Spec Suite failed")
+end
+
+begin
+  require 'jeweler'
+  Jeweler::Tasks.new do |s|
+    s.name = "rr"
+    s.summary = "RR (Double Ruby) is a double framework that features a rich " <<
+                "selection of double techniques and a terse syntax. " <<
+                "http://xunitpatterns.com/Test%20Double.html"
+    s.email = "brian@pivotallabs.com"
+    s.homepage = "http://pivotallabs.com"
+    s.description = "RR (Double Ruby) is a double framework that features a rich " <<
+                    "selection of double techniques and a terse syntax. " <<
+                    "http://xunitpatterns.com/Test%20Double.html"
+    s.authors = ["Brian Takita"]
+    s.files = FileList[
+      '[A-Z]*',
+      '*.rb',
+      'lib/**/*.rb',
+      'spec/**/*.rb'
+    ].to_a
+    s.test_files = Dir.glob('spec/*_spec.rb')
+    s.has_rdoc = true
+    s.extra_rdoc_files = [ "README.rdoc", "CHANGES" ]
+    s.rdoc_options = ["--main", "README.rdoc", "--inline-source", "--line-numbers"]
+    s.rubyforge_project = "pivotalrb"
+  end
+rescue LoadError
+  puts "Jeweler not available. Install it with: sudo gem install technicalpickles-jeweler -s http://gems.github.com"
+end
+RUBYFORGE_PACKAGE_NAME = "rr (Double Ruby)"
+# The package was renamed from "rr (Double R)" to "rr (Double Ruby)".
+# When this was last run, the script did not work for the new name but it did work for the old name.
+# Perhaps more time was needed for the name change to propagate?
+#RUBYFORGE_PACKAGE_NAME = "rr (Double R)"
+
+# This is hacked to get around the 3 character limitation for package names on Rubyforge.
+# http://rubyforge.org/tracker/index.php?func=detail&aid=27026&group_id=5&atid=102
+class Jeweler
+  module Commands
+    class ReleaseToRubyforge
+      def run
+        raise NoRubyForgeProjectInGemspecError unless @gemspec.rubyforge_project
+
+        @rubyforge.configure rescue nil
+
+        output.puts 'Logging in rubyforge'
+        @rubyforge.login
+
+        @rubyforge.userconfig['release_notes'] = @gemspec.description if @gemspec.description
+        @rubyforge.userconfig['preformatted'] = true
+
+        output.puts "Releasing #{@gemspec.name}-#{@version} to #{@gemspec.rubyforge_project}"
+        begin
+          @rubyforge.add_release(@gemspec.rubyforge_project, RUBYFORGE_PACKAGE_NAME, @version.to_s, @gemspec_helper.gem_path)
+        rescue StandardError => e
+          case e.message
+          when /no <group_id> configured for <#{Regexp.escape @gemspec.rubyforge_project}>/
+            raise RubyForgeProjectNotConfiguredError, @gemspec.rubyforge_project
+          when /no <package_id> configured for <#{Regexp.escape @gemspec.name}>/i
+            raise MissingRubyForgePackageError, @gemspec.name
+          else
+            raise
+          end
+        end
+      end
+    end
+  end
+end

data/vendor/bundle/ruby/1.9.1/gems/rr-1.0.4/benchmarks/rr_benchmark.rb

@@ -0,0 +1,32 @@
+dir = File.dirname(__FILE__)
+require File.expand_path("#{dir}/../lib/rr")
+require "benchmark"
+
+o = Object.new
+
+Benchmark.bm do |x|
+  x.report do
+    1000.times do
+      RR.mock(o).foobar.returns("baz")
+      o.foobar
+      RR.reset
+    end
+  end
+end
+
+#require "ruby-prof"
+#RubyProf.start
+#
+##RR.mock(o).foobar.returns("baz")
+##o.foobar
+#10.times do
+#  RR.mock(o).foobar.returns("baz")
+#  o.foobar
+#  RR.reset
+#end
+#
+#result = RubyProf.stop
+#
+## Print a flat profile to text
+#printer = RubyProf::FlatPrinter.new(result)
+#printer.print(STDOUT, 0)

data/vendor/bundle/ruby/1.9.1/gems/rr-1.0.4/benchmarks/rspec_benchmark.rb

@@ -0,0 +1,14 @@
+require "rubygems"
+require "spec/mocks"
+require "benchmark"
+
+o = Object.new
+
+Benchmark.bm do |x|
+  x.report do
+    1000.times do
+      o.should_receive(:foobar).and_return("baz")
+      o.foobar
+    end
+  end
+end

data/vendor/bundle/ruby/1.9.1/gems/rr-1.0.4/doc/0.6.0.release.markdown

@@ -0,0 +1,81 @@
+I'm pleased to announce the 0.6.0 version of RR. The [changes](http://github.com/btakita/rr/tree/master%2FCHANGES?raw=true) include:
+
+  * Declaring Double subject objects without having to pass it in via the mock!, stub!, dont_allow!, instance_of!, and proxy! methods
+  * Revised Double chaining API
+  * satisfy matcher
+  * hash_including matcher
+
+# Declaring Double Subjects (The bang methods)
+
+In previous versions of RR, you always needed to pass in the subject of the double. For example:
+
+    subject = Object.new
+    mock(subject).does_something {:and_returns_me}
+    subject.does_something # :and_returns_me
+
+Now you can have RR automatically create the subject object for you by using the ! method:
+
+    subject = mock!.does_something {:and_returns_me}.subject
+    subject.does_something # :and_returns_me
+
+Now the bang methods by themselves don't really add a whole lot, but when used in the context of Double chaining, they become a powerful addition.
+
+# Double Chaining
+
+Nick Kallen presented the use case for Double chaining and contributed a patch for the 0.5.0 release of RR. It has proved useful and is now more fully incorporated into RR. Now you can pass in your subject or use the subject provided by RR by using the ! method. Here are some examples of Double Chaining:
+
+    mock(subject).first(1) {mock(Object.new).second(2) {mock(Object.new).third(3) {4}}}
+    subject.first(1).second(2).third(3) # 4
+
+    mock(subject).first(1) {mock!.second(2) {mock!.third(3) {4}}}
+    subject.first(1).second(2).third(3) # 4
+      
+    mock(subject).first(1).mock!.second(2).mock!.third(3) {4}
+    subject.first(1).second(2).third(3) # 4
+
+Of course you have access to the proxy facilities:
+
+    mock.proxy(User).find('1').mock.proxy!.children.mock.proxy!.find_all_by_group_id(10)
+    User.find('1').children.find_all_by_group_id(10) # Makes verifications pass and returns the actual children
+
+You can also do branched Double chaining:
+
+    mock(subject).first do
+      mock! do |expect|
+        expect.branch1.mock!.branch11 {11} # or expect.branch1 {mock!.branch11 {11}}
+        expect.branch2.mock!.branch22 {22} # or expect.branch2 {mock!.branch22 {22}}
+      end
+    end
+    o = subject.first
+    o.branch1.branch11 # 11
+    o.branch2.branch22 # 22
+
+# Satisfy Matcher
+
+Matthew O'Conner submitted a patch that added the satisfy matcher. This adds the ability to add arbitrary argument expectation matchers.
+
+    mock(object).foobar(satisfy {|arg| arg.length == 2})
+    object.foobar("xy")
+
+
+# Hash Including Matcher
+
+Matthew O'Conner also submitted a patch that added the hash_including matcher. This adds a convenient way to assert that the passed-in hash includes certain key/value pairs.
+
+    mock(object).foobar(hash_including(:red => "#FF0000", :blue => "#0000FF"))
+    object.foobar({:red => "#FF0000", :blue => "#0000FF", :green => "#00FF00"})
+
+# Mailing list
+
+RR has a mailing lists at:
+
+* [double-ruby-users@rubyforge.org](mailto:double-ruby-users@rubyforge.org)
+* [double-ruby-devel@rubyforge.org](mailto:double-ruby-devel@rubyforge.org)
+
+Also, RR's rubyforge page is at [http://rubyforge.org/projects/double-ruby](http://rubyforge.org/projects/double-ruby) and of course the github page is at [http://github.com/btakita/rr](http://github.com/btakita/rr).
+
+# Yes, and there is more to come
+
+There are many interesting ideas floating around. Joseph Wilk has been playing around with [adding Spies](http://github.com/JoeSniff/rr) into RR. I'm also thinking about adding Double validation scoping into RR. Also, I'm impressed by Mocha's warning of unused stubs. Josh Susser also proposed having a mode where a warning would occur if a mocked method is not implemented on the subject being mocked.
+
+If you have any feature requests, please send an email to the mailing list or add it to the rubyforge tracker.

data/vendor/bundle/ruby/1.9.1/gems/rr-1.0.4/introducting_rr.txt

@@ -0,0 +1,206 @@
+**Introducting RR**
+
+I'm pleased to introduce a new Test Double framework names RR, which is short for Double Ruby.
+A Test Double is [double description]. You can read more about test doubles at http://xunitpatterns.com/Test%20Double.html.
+
+RR supports the following constructs:
+ * Mock
+ * Stub
+ * instance_of
+ * Probe
+
+**Mock**
+<pre>
+  real_user = User.new
+  mock(User).find('2') {real_user}
+</pre>
+
+The previous example overrides the User.find method and returns real_user. It also sets an expectation
+that the find method will receive the argument '2' once.
+
+**Stub**
+<pre>
+  user = User.new
+  my_article = articles(:my_article)
+  stub(user).can_edit?(my_article) {true}
+</pre>
+
+The previous example overrides can_edit?. When the method receives the article, it returns true.
+
+**instance_of**
+You can mock or stub instances of a class.
+<pre>
+  stub.instance_of(User).can_edit?(my_article) {true}
+</pre>
+
+The previous example stubs the can_edit? method of any intstance of User.
+
+**Probe**
+
+A probe is a test double strategy that lets the real method implementation be called, and allows you
+to intercept the return value, and possibly inject you own replacement return value.
+<pre>
+  my_article = articles(:my_article)
+  mock.probe(User).find('2') do |real_user|
+    stub.probe(real_user).can_edit?(my_article) {true}
+    real_user
+  end
+</pre>
+
+The previous example, lets the real User.find method call happen, and intercepts its return value inside
+of the block.
+
+The real_user's can_edit? method is then stubbed and probed to return true.
+
+**Thats nice, how is it useful?**
+
+As with any tool, Mocks and Stubs have limitations.
+For example, mocks alone do not verify that the mocked out method conforms to the real object's interface.
+Probes solve this issue.
+
+Adding a probe ensures that:
+ * The method call to User.find is valid
+ * The return value of User.find is available to validate and/or add test doubles to
+ * The method call to real_user.can_edit? is valid
+
+**I don't use Mocks. Why should I care?**
+
+State based testing is often the simplest and most straightforward way to make assertions.
+However Interaction assertions can serve as good documentation of how your system fits together.
+Interaction tests can also aid you in making your tests easier to set up and removing coupling between tests.
+
+Lets compare the state and interaction testing approaches in the can edit article example for the
+ArticlesController#edit action:
+
+**State Based Example**
+<pre>
+  user = users(:bob)
+  login(user)
+  my_article = articles(:my_article)
+  user.can_edit?(my_article).should == false
+
+  lambda do
+    post :edit, :id => my_article.id, :body => "Hello everybody"
+  end.should raise_error(SecurityTrangressionError)
+</pre>
+
+**Interaction Based Example**
+<pre>
+  user = users(:bob)
+  login(user)
+  my_article = articles(:my_article)
+  mock.probe(user).can_edit? {false}
+
+  lambda do
+    post :edit, :id => my_article.id, :body => "Hello everybody"
+  end.should raise_error(SecurityTrangressionError)
+</pre>
+
+These two examples are interesting because they verify slight different things.
+The interaction example states that when can_edit? with @article is called and returns false, a SecurityTrangressionError
+is raised.
+The state example gives information that bob cannot edit the article, and from that one can infer that
+bob trying to edit the article will raise a SecurityTrangressionError.
+
+State based testing tends to be more coupling than interaction based testing.
+Note that coupling is not necessarily bad.
+The state based example has both interface, data, and knowledge coupling compared to the interaction based test:
+ * Interface coupling - If can_edit? does not return false, there is an error.
+ * Fixture Data coupling - If the fixture data changes, there is an error.
+ * Knowledge coupling - The ArticleController test needs to know how can_edit? returns false
+
+Interface coupling is actually a good thing, because it verifies the User and ArticleController work
+together proberly. This sort of testing is functional or integration testing.
+
+The Data and Knowledge coupling are not desirable characteristics because they cause the
+developer to be concerned about another part of the system, which takes development time.
+It can also cause unwanted test failures when the global fixture data is changed or when a change
+occurs that makes the ArticleController's test setup logic incorrect.
+
+Martin Fowler also notes that interaction testing has coupling to the edit action's implementation,
+in that the interaction example states that User#can_edit? must be called for the test to pass.
+I've found that sometimes this is desirable and sometimes it is not desirable.
+
+The coupling to the implementation encourages more decomposition but it also makes
+causes brittleness because changing the edit action to call another method will cause
+the test to fail.
+
+I'm not proposing the right solution in this case, because it is dependent on
+your situation. One thing to consider is:
+ * Do you have functional or integration tests for the failure case?
+
+Taking the desirable and undesirable coupling into account
+
+Here is a view example that renders counts:
+
+**State Based Example**
+<pre>
+  user = users(:bob)
+  user.articles.count.should == 5
+  user.articles.comments.count.should == 15
+  user.gold_stars.count.should == 0
+
+  render :template => "users/show"
+  response.body.should include("Articles Posted: 5")
+  response.body.should include("Comments Received: 15")
+  response.body.should include("Gold Stars Received: 0")
+</pre>
+
+**Interaction Based Example**
+<pre>
+  user = User.new
+  mock.probe(user.articles).count {5}
+  mock.probe(user.articles.comments).count {15}
+  mock.probe(user.gold_stars).count {80}
+
+  render :template => "users/show"
+  response.body.should include("Articles Posted: 5")
+  response.body.should include("Comments Received: 15")
+  response.body.should include("Gold Stars Received: 80")
+</pre>
+
+The same tradeoffs are present in this view example as in the ActiclesController example,
+but the values of each of the tradeoffs are different.
+
+State testing couplings:
+ * Interface coupling - If count returns a non-number, there is an error.
+ * Fixture Data coupling - If the fixture data changes, there is an error.
+ * Knowledge coupling - There is no noticeable knowledge coupling.
+
+Interaction testing couplings:
+ * Implementation coupling - If the way the count is determined changes, there is an error.
+
+In these examples, it is fair to expect the counts derived from the fixtures to change quite often.
+Decoupling the counts from your fixtures yields more of a benefit because the interaction based example
+will probably not need to be changed as often as the state based example.
+
+The interaction based example also provides the benefits of:
+ * being faster because there is no database access
+ * providing more focus because non-count user data is not important to this example (the interaction example
+   ignores the user data while the state based approach includes the user data)
+ * not requiring you to change the fixture data to provide add "Gold Stars Received" because having
+   "Gold Stars Received: 0" is almost meaningless (It could easily be calling count on something else
+   that returns 0)
+
+**State vs. Interaction Based testing?**
+
+The examples I provided favor or are neutral to interaction based testing.
+This does not mean all testing should be done with interaction testing.
+There are many situations where state based testing is more
+straightforward and no more coupled than an interaction based test.
+
+Please pick the right toolset for your situation.
+In the future, I will blog about different situations and the trade-offs of
+using a state based approach, and/or an interaction based approach.
+
+**Extremely Bad Examples**
+
+Since this is a blog post, the examples are short and relatively benign.
+However, There are many examples where state and/or interaction
+based testing is overused and abused.
+Expanding your toolset can help you and your coworkers fix these issues.
+
+There are already several nice Mock/Stub frameworks in the ruby world. These libraries include:
+ * Mocha
+ * Flexmock
+ * Rspec's Mock Framework

data/vendor/bundle/ruby/1.9.1/gems/rr-1.0.4/lib/rr/adapters/minitest.rb

@@ -0,0 +1,31 @@
+module RR
+  module Adapters
+    module MiniTest
+      include RRMethods
+      def self.included(mod)
+        RR.trim_backtrace = true
+        mod.class_eval do
+          unless instance_methods.any? { |method_name| method_name.to_sym == :setup_with_rr }
+            alias_method :setup_without_rr, :setup
+            def setup_with_rr
+              setup_without_rr
+              RR.reset
+            end
+            alias_method :setup, :setup_with_rr
+
+            alias_method :teardown_without_rr, :teardown
+            def teardown_with_rr
+              RR.verify
+              teardown_without_rr
+            end
+            alias_method :teardown, :teardown_with_rr
+          end
+        end
+      end
+
+      def assert_received(subject, &block)
+        block.call(received(subject)).call
+      end
+    end
+  end
+end