lookout 2.3.0 → 3.0.0

data/test/unit/lookout-3.0/reception.rb

@@ -0,0 +1,86 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect NoMethodError.
+    new("cannot convert upper reception limit to Integer: undefined method `to_int' for nil:NilClass") do
+    Object.new.to.receive.a.at_most(nil)
+  end
+
+  expect ArgumentError.new('upper reception limit must be positive: -1 < 1') do
+    Object.new.to.receive.a.at_most(-1)
+  end
+
+  expect ArgumentError.new('upper reception limit must be positive: 0 < 1') do
+    Object.new.to.receive.a.at_most(0)
+  end
+
+  expect Lookout::Reception do
+    Object.new.to.receive.a.at_most(1)
+  end
+
+  expect ArgumentError.new('expected reception count must be non-negative: -1 < 0') do
+    Object.new.to.receive.a.exactly(-1)
+  end
+
+  expect Lookout::Reception do
+    Object.new.to.receive.a.exactly(0)
+  end
+
+  expect ArgumentError.new('lower reception limit must be positive: -1 < 1') do
+    Object.new.to.receive.a.at_least(-1)
+  end
+
+  expect ArgumentError.new('lower reception limit must be positive: 0 < 1') do
+    Object.new.to.receive.a.at_least(0)
+  end
+
+  expect Lookout::Reception do
+    Object.new.to.receive.a.at_least(1)
+  end
+
+  expect Lookout::Results::Success.new('test', 1) do
+    stub.to.receive.call.to_lookout_expected.expect('test', 1){ |o| o.call }.call
+  end
+
+  expect Lookout::Results::Failure do
+    stub.to.receive.call.to_lookout_expected.expect('test', 1).call
+  end
+
+  if RUBY_VERSION < '1.9'
+    expect Lookout::Results::Error do
+      stub.to.receive.call.to_lookout_expected.expect('test', 1){ raise RuntimeError, 'error', [] }.call
+    end
+  else
+    expect Lookout::Results::Error.new('test', 1, nil, Lookout::Exception.new(RuntimeError.new('error').tap{ |e| e.set_backtrace([]) })) do
+      stub.to.receive.call.to_lookout_expected.expect('test', 1){ raise RuntimeError, 'error', [] }.call
+    end
+  end
+
+  expect Lookout::Results::Error do
+    stub.not.to.receive.call.to_lookout_expected.expect('test', 1){ |o| o.call }.call
+  end
+
+  expect 'stub#call: unexpected number of invocations (1 for 0)' do
+    stub.not.to.receive.call.to_lookout_expected.expect('test', 1){ |o| o.call }.call.exception.message
+  end
+
+  expect Lookout::Results::Success.new('test', 1) do
+    stub.not.to.receive.call.to_lookout_expected.expect('test', 1).call{ }
+  end
+
+  expect Lookout::Results::Error do
+    stub.to.receive.call(1).to_lookout_expected.expect('test', 1){ |o| o.call }.call
+  end
+
+  expect 'stub#call: unexpected arguments: []≠[1]' do
+    stub.to.receive.call(1).to_lookout_expected.expect('test', 1){ |o| o.call }.call.exception.message
+  end
+
+  expect Lookout::Results::Error do
+    stub.to.receive.call(1).to_lookout_expected.expect('test', 1){ |o| o.call(1, 2) }.call
+  end
+
+  expect 'stub#call: unexpected arguments: [1, 2]≠[1]' do
+    stub.to.receive.call(1).to_lookout_expected.expect('test', 1){ |o| o.call(1, 2) }.call.exception.message
+  end
+end

data/test/unit/lookout-3.0/reception/arguments.rb

@@ -0,0 +1,23 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect Lookout::Reception::Arguments::Any do
+    Lookout::Reception::Arguments.for
+  end
+
+  expect Lookout::Reception::Arguments::Any do
+    Lookout::Reception::Arguments.for(1, Lookout::Reception::Arguments::Any.new)
+  end
+
+  expect Lookout::Reception::Arguments::None do
+    Lookout::Reception::Arguments.for(Lookout::Reception::Arguments::None.new)
+  end
+
+  expect Lookout::Reception::Arguments::None do
+    Lookout::Reception::Arguments.for(1, Lookout::Reception::Arguments::None.new)
+  end
+
+  expect Lookout::Reception::Arguments::List.new(1, 2, 3) do
+    Lookout::Reception::Arguments.for(1, 2, 3)
+  end
+end

data/test/unit/lookout-3.0/reception/arguments/any.rb

@@ -0,0 +1,15 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect '*args, &block' do
+    Lookout::Reception::Arguments::Any.new.to_s
+  end
+
+  expect true do
+    Lookout::Reception::Arguments::Any.new =~ []
+  end
+
+  expect true do
+    Lookout::Reception::Arguments::Any.new =~ [1, 2, 3]
+  end
+end

data/test/unit/lookout-3.0/reception/arguments/error.rb

@@ -0,0 +1,4 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+end

data/test/unit/lookout-3.0/reception/arguments/list.rb

@@ -0,0 +1,19 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect true do
+    Lookout::Reception::Arguments::List.new(1, Object, 3) =~ [1, 2, 3]
+  end
+
+  expect false do
+    Lookout::Reception::Arguments::List.new(1, 4, 3) =~ [1, 2, 3]
+  end
+
+  expect '1, 2, 3' do
+    Lookout::Reception::Arguments::List.new(1, 2, 3).to_s
+  end
+
+  expect '1, (cannot inspect argument: error), 3' do
+    Lookout::Reception::Arguments::List.new(1, stub(:inspect => proc{ raise 'error' } ), 3).to_s
+  end
+end

data/test/unit/lookout-3.0/reception/arguments/none.rb

@@ -0,0 +1,15 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect true do
+    Lookout::Reception::Arguments::None.new =~ []
+  end
+
+  expect false do
+    Lookout::Reception::Arguments::None.new =~ [1, 2, 3]
+  end
+
+  expect '' do
+    Lookout::Reception::Arguments::None.new.to_s
+  end
+end

data/test/unit/lookout-3.0/reception/error.rb

@@ -0,0 +1,4 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+end

data/test/unit/lookout-3.0/result.rb

@@ -0,0 +1,27 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect true do
+    Lookout::Results::Success.new('a', 1) == Lookout::Results::Success.new('a', 1)
+  end
+
+  expect false do
+    Lookout::Results::Success.new('a', 1) == Lookout::Results::Success.new('a', 2)
+  end
+
+  expect false do
+    Lookout::Results::Success.new('a', 1) == Lookout::Results::Success.new('b', 1)
+  end
+
+  expect 'test:1' do
+    Lookout::Results::Success.new('test', 1).to_s
+  end
+
+  expect 'test' do
+    Lookout::Results::Success.new('test', 1).file
+  end
+
+  expect 1 do
+    Lookout::Results::Success.new('test', 1).line
+  end
+end

data/test/unit/lookout-3.0/results.rb

@@ -0,0 +1,4 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+end

data/test/unit/lookout-3.0/results/error.rb

@@ -0,0 +1,37 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  # In Ruby 1.8.7, exceptions can’t be compared properly.
+  if RuntimeError.new == RuntimeError.new
+    expect true do
+      Lookout::Results::Error.new('a', 1, nil, Lookout::Exception.new(RuntimeError.new)) ==
+        Lookout::Results::Error.new('a', 1, nil, Lookout::Exception.new(RuntimeError.new))
+    end
+
+    expect false do
+      Lookout::Results::Error.new('a', 1, nil, Lookout::Exception.new(RuntimeError.new)) ==
+                                  Lookout::Results::Error.new('a', 1, 'a', Lookout::Exception.new(RuntimeError.new))
+    end
+
+    expect false do
+Lookout::Results::Error.new('a', 1, nil, Lookout::Exception.new(RuntimeError.new)) ==
+                            Lookout::Results::Error.new('a', 1, nil, Lookout::Exception.new(StandardError.new))
+    end
+
+    expect Lookout::Exception.new(RuntimeError.new('error')) do
+      Lookout::Results::Error.new('test', 1, 'a≠b', Lookout::Exception.new(RuntimeError.new('error'))).exception
+    end
+  end
+
+  expect "test:1: error (RuntimeError)\n" do
+    Lookout::Results::Error.new('test', 1, nil, Lookout::Exception.new(RuntimeError.new('error'))).to_s
+  end
+
+  expect "test:1: a≠b: error (RuntimeError)\n" do
+    Lookout::Results::Error.new('test', 1, 'a≠b', Lookout::Exception.new(RuntimeError.new('error'))).to_s
+  end
+
+  expect 'a≠b' do
+    Lookout::Results::Error.new('test', 1, 'a≠b', Lookout::Exception.new(RuntimeError.new('error'))).message
+  end
+end

data/test/unit/lookout-3.0/results/failure.rb

@@ -0,0 +1,21 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect "test:1: 2≠1" do
+    Lookout::Results::Failure.new('test', 1, 1.to_lookout_expected.difference(2)).to_s
+  end
+
+  expect 'test:1: "b"≠"a": [-b-]{+a+}' do
+    Lookout::Results::Failure.new('test', 1, 'a'.to_lookout_expected.difference('b')).to_s
+  end
+
+  expect <<EOM.chomp do
+test:1: "b\\nc"≠"a"
+@@ -1,2 +1,1 @@
+-b
+-c
++a
+EOM
+    Lookout::Results::Failure.new('test', 1, 'a'.to_lookout_expected.difference("b\nc")).to_s
+  end
+end

data/test/unit/lookout-3.0/results/success.rb

@@ -0,0 +1,4 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+end

data/test/unit/lookout-3.0/stub.rb

@@ -0,0 +1,53 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect 'stub' do
+    Lookout::Stub.new.inspect
+  end
+
+  expect Lookout::Stub.new do |o|
+    o.any_old_method
+  end
+
+  expect Lookout::Stub.new do |o|
+    o.any_old_method_with_various_arguments(1, [], {})
+  end
+
+  expect Lookout::Stub.new do |o|
+    o.any_old_method_with_a_block{ }
+  end
+
+  if proc{ }.respond_to? :lambda?
+    expect ArgumentError do
+      Lookout::Stub.new(:a => lambda{ 1 }).a(2)
+    end
+  end
+
+  expect 1 do
+    Lookout::Stub.new(:a => proc{ 1 }).a(2)
+  end
+
+  expect 1 do
+    Lookout::Stub.new(:a => proc{ 1 }).a
+  end
+
+  expect 1 do
+    Lookout::Stub.new(:a => proc{ |i| i }).a(1)
+  end
+
+  expect 1 do
+    Lookout::Stub.new(:a => proc{ |&b| b.call }).a{ 1 }
+  end
+
+  expect 1 do
+    Lookout::Stub.new(:a => 1).a
+  end
+
+  expect 1 do
+    Lookout::Stub.new(:a => 1).a(2)
+  end
+
+  expect 1 do
+    Lookout::Stub.new(:a => 1).a(2){ 3 }
+  end
+end

data/test/unit/lookout-3.0/version.rb

@@ -0,0 +1,4 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+end

data/test/unit/lookout-3.0/warning.rb

@@ -0,0 +1,47 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect true do
+    Lookout::Warning.new('a') == Lookout::Warning.new('a')
+  end
+
+  expect true do
+    Lookout::Warning.new('a') == Lookout::Warning.new("a\n")
+  end
+
+  expect false do
+    Lookout::Warning.new('a') == Lookout::Warning.new('b')
+  end
+
+  expect false do
+    Lookout::Warning.new('a') == Lookout::Warning.new("b\n")
+  end
+
+  expect true do
+    Lookout::Warning.new('a') === Lookout::Warning.new('/a/b/c:1: warning: a')
+  end
+
+  expect true do
+    Lookout::Warning.new('a') === Lookout::Warning.new("/a/b/c:1: warning: a\n")
+  end
+
+  expect false do
+    Lookout::Warning.new('a') === Lookout::Warning.new('/a/b/c:1: warning: b')
+  end
+
+  expect false do
+    Lookout::Warning.new('a') === Lookout::Warning.new("/a/b/c:1: warning: b\n")
+  end
+
+  expect '[-b-]{+a+}' do
+    Lookout::Warning.new('a').diff(Lookout::Warning.new("/a/b/c:1: warning: b\n")).to_s
+  end
+
+  expect 'warning("this is your final one!")' do
+    Lookout::Warning.new('this is your final one!').inspect
+  end
+
+  expect 'warning("this is your final one!")' do
+    Lookout::Warning.new("this is your final one!\n").inspect
+  end
+end

metadata

@@ -1,478 +1,1183 @@
 --- !ruby/object:Gem::Specification
 name: lookout
 version: !ruby/object:Gem::Version
-  version: 2.3.0
-  prerelease: 
+  version: 3.0.0
 platform: ruby
 authors:
 - Nikolai Weibull
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2011-10-20 00:00:00.000000000 Z
+date: 2013-04-30 00:00:00.000000000 Z
 dependencies:
+- !ruby/object:Gem::Dependency
+  name: inventory
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.4'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.4'
+- !ruby/object:Gem::Dependency
+  name: inventory-rake
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.4'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.4'
+- !ruby/object:Gem::Dependency
+  name: inventory-rake-tasks-yard
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.3'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.3'
+- !ruby/object:Gem::Dependency
+  name: lookout-rake
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '3.0'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '3.0'
 - !ruby/object:Gem::Dependency
   name: yard
-  requirement: &14532168 !ruby/object:Gem::Requirement
-    none: false
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: 0.8.0
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: 0.8.0
+- !ruby/object:Gem::Dependency
+  name: yard-heuristics
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.1'
+  type: :development
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.1'
+- !ruby/object:Gem::Dependency
+  name: yard-value
+  requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: 0.6.0
+        version: '1.2'
   type: :development
   prerelease: false
-  version_requirements: *14532168
-description: ! "                                Lookout\n\n  Lookout is a lightweight
-  unit testing framework. Tests (expectations) can be\n  written as follows\n\n    expect
-  2 do\n      1 + 1\n    end\n\n    expect NoMethodError do\n      Object.invalid_method_call\n
-  \   end\n\n  Lookout is designed to encourage – force, even – unit testing best
-  practices\n  such as\n\n•   Setting up only one expectation per test\n•   Not setting
-  expectations on non-public APIs\n•   Test isolation\n\n  This is done by\n\n•   Only
-  allowing one expectation to be set per test\n•   Providing no (additonal) way of
-  accessing private state\n•   Providing no setup and teardown methods, nor a method
-  of providing test\n    helpers\n\n  Other important points are\n\n•   A unified
-  syntax for setting up both state-based and behavior-based\n    expectations\n•   A
-  focus on code readability by providing no mechanism for describing an\n    expectation
-  other than the code in the expectation itself\n\n  The way Lookout works has been
-  heavily influenced by expectations¹, by\n  {Jay Fields}².  The code base was once
-  also heavily based on expectations¹,\n  based at Subversion {revision 76}³.  A lot
-  has happened since then and all of\n  the work past that revision are due to {Nikolai
-  Weibull}⁴.\n\n¹ Get more information on the expectations library at http://expectations.rubyforge.org/\n²
-  Read Jay Fields’s blog at http://blog.jayfields.com/\n³ Review Lookout revision
-  76 at https://github.com/now/lookout/commit/537bedf3e5b3eb4b31c066b3266f42964ac35ebe\n⁴
-  Visit Nikolai Weibull’s home page at http://bitwi.se/\n\n§ Installation\n\n    Install
-  Lookout with\n\n      % gem install lookout\n\n\n§ Usage\n\n    Lookout allows you
-  to set expectations on an object’s state or behavior.\n    We’ll begin by looking
-  at state expectations and then take a look at\n    expectations on behavior.\n\n
-  \ § Expectations on State\n\n      An expectation can be made on the result of a
-  computation:\n\n        expect 2 do\n          1 + 1\n        end\n\n      Most
-  objects, in fact, have their state expectations checked by invoking\n      ‹#==›
-  on the expected value with the result as its argument.\n\n      Checking that a
-  result is within a given range is also simple:\n\n        expect 0.099..0.101 do\n
-  \         0.4 - 0.3\n        end\n\n      Here, the more general ‹#===› is being
-  used on the ‹Range›.\n\n      ‹Strings› of course match against ‹Strings›:\n\n        expect
-  'ab' do\n          'abc'[0..1]\n        end\n\n      but we can also match a ‹String›
-  against a ‹Regexp›:\n\n        expect %r{a substring} do\n          'a string with
-  a substring'\n        end\n\n      (Note the use of ‹%r{…}› to avoid warnings that
-  will be generated when\n      Ruby parses ‹expect /…/›.)\n\n      Checking that
-  the result includes a certain module is done by expecting the\n      ‹Module›.\n\n
-  \       expect Enumerable do\n          []\n        end\n\n      This, due to the
-  nature of Ruby, of course also works for classes (as\n      they are also modules):\n\n
-  \       expect String do\n          'a string'\n        end\n\n      This doesn’t
-  hinder us from expecting the actual ‹Module› itself:\n\n        expect Enumerable
-  do\n          Enumerable\n        end\n\n      As you may have figured out yourself,
-  this is accomplished by first\n      trying ‹#==› and, if it returns ‹false›, then
-  trying ‹#===› on the\n      expected ‹Module›.  This is also true of ‹Ranges› and
-  ‹Regexps›.\n\n      Truthfulness is expected with ‹true› and ‹false›:\n\n        expect
-  true do\n          1\n        end\n\n        expect false do\n          nil\n        end\n\n
-  \     Results equaling ‹true› or ‹false› are slightly different:\n\n        expect
-  TrueClass do\n          true\n        end\n\n        expect FalseClass do\n          false\n
-  \       end\n\n      The rationale for this is that you should only care if the
-  result of a\n      computation evaluates to a value that Ruby considers to be either
-  true or\n      false, not the exact literals ‹true› or ‹false›.\n\n      Expecting
-  output on an IO object is also common:\n\n        expect output(\"abc\\ndef\\n\")
-  do |io|\n          io.puts 'abc', 'def'\n        end\n\n      This can be used to
-  capture the output of a formatter that takes an\n      output object as a parameter.\n\n
-  \     You should always be expecting errors from – and in, but that’s a\n      different
-  story – your code:\n\n        expect NoMethodError do\n          Object.no_method\n
-  \       end\n\n      Often, not only the type of the error, but its description,
-  is important\n      to check:\n\n        expect StandardError.new('message') do\n
-  \         raise StandardError.new('message')\n        end\n\n      As with ‹Strings›,
-  ‹Regexps› can be used to check the error description:\n\n        expect StandardError.new(/mess/)
-  do\n          raise StandardError.new('message')\n        end\n\n      (Note that
-  some of Ruby’s built-in error classes have slightly\n      complicated behavior
-  and will not allow you to pass a ‹Regexp› as a\n      parameter.  ‹NameError› is
-  such a class.  This may warrant further\n      investigation into whether or not
-  this is a bug, but I’ll leave that up\n      to the reader to decide.)\n\n      Lookout
-  further provides a fluent way of setting up expectations on\n      boolean results.
-  \ An object can “be”\n\n        expect Class.new{ attr_accessor :running; }.new.to.be.running
-  do |process|\n          process.running = true\n        end\n\n      or “not be”\n\n
-  \       expect Class.new{ attr_accessor :running; }.new.not.to.be.running do |process|\n
-  \         process.running = false\n        end\n\n      or to “have”\n\n        expect
-  Class.new{ attr_accessor :finished; }.new.to.have.finished do |process|\n          process.finished
-  = true\n        end\n\n      or “not have”\n\n        expect Class.new{ attr_accessor
-  :finished; }.new.not.to.have.finished do |process|\n          process.finished =
-  false\n        end\n\n      On the same note\n\n        expect nil.to.be.nil?\n\n
-  \     and\n\n        expect Object.new.not.to.be.nil?\n\n      As not every boolean
-  method “is” or “has” you can even\n\n        expect nil.to.respond_to? :nil?\n\n
-  \     The rules here are that all ‹Objects› respond to ‹#to›.  After ‹#to› you\n
-  \     may call\n\n    •   ‹#not›\n    •   ‹#be›\n    •   ‹#have›\n    •   Any method
-  whose name ends with ‹?›\n\n      A call to ‹#not› must be followed by a call to
-  one of the three\n      alternatives that follow it in the list.  ‹#Be› and ‹#have›
-  must be\n      followed by a call to a method.\n\n  § Expectations on Behavior\n\n
-  \     We expect our objects to be on their best behavior.  Lookout allows you\n
-  \     to make sure that they are.\n\n      Mocks let use verify that a method is
-  called in the way that we expect it\n      to be:\n\n        expect mock.to.receive.dial('2125551212').twice
-  do |phone|\n          phone.dial('2125551212')\n          phone.dial('2125551212')\n
-  \       end\n\n      Here, ‹#mock› creates a mock object, an object that doesn’t
-  respond to\n      anything unless you tell it to.  We tell it to expect to receive
-  a call\n      to ‹#dail› with ‹'2125551212'› as its formal argument, and we expect
-  it\n      to receive it twice.  The mock object is then passed in to the block so\n
-  \     that the expectations placed upon it can be fulfilled.\n\n      Sometimes
-  we only want to make sure that a method is called in the way\n      that we expect
-  it to be, but we don’t care if any other methods are\n      called on the object.
-  \ A stub object, created with ‹#stub›, expects any\n      method and returns a stub
-  object that, again, expects any method, and\n      thus fits the bill.\n\n        expect
-  stub.to.receive.dial('2125551212').twice do |phone|\n          phone.dial('2125551212')\n
-  \         phone.hangup\n          phone.dial('2125551212')\n        end\n\n      We
-  can also use stubs without any expectations on them:\n\n        expect 3 do\n          s
-  = stub(:a => 1, :b => 2)\n          s.a + s.b\n        end\n\n      Blocks are also
-  allowed:\n\n        expect 3 do\n          s = stub(:a => proc{ |a, b| a + b })\n
-  \         s.a(1, 2)\n        end\n\n      If need be, we can stub out a specific
-  method on an object:\n\n        expect 'def' do\n          a = 'abc'\n          stub(a).to_str{
-  'def' }\n          a.to_str\n        end\n\n      You don’t have to use a mock object
-  to verify that a method is called:\n\n        expect Object.to.receive.deal do\n
-  \         Object.deal\n        end\n\n      As you have figured out by now, the
-  expected method call is set up by\n      calling ‹#receive› after ‹#to›.  ‹#Receive›
-  is followed by a call to the\n      method to expect with any expected arguments.
-  \ The body of the mocked\n      method can be given as the block to the method.
-  \ Finally, an expected\n      invocation count may follow the method.  Let’s look
-  at this formal\n      specification in more detail.\n\n      The expected method
-  arguments may be given in a variety of ways.  Let’s\n      introduce them by giving
-  some examples:\n\n        expect mock.to.receive.a do |m|\n          …\n        end\n\n
-  \     Here, the method ‹#a› must be called with any number of arguments.  It\n      may
-  be called any number of times, but it must be called at least once.\n\n      If
-  a method must receive exactly one argument, you can use ‹arg›:\n\n        expect
-  mock.to.receive.a(arg) do |m|\n          …\n        end\n\n      If a method must
-  receive a specific argument, you can use that argument:\n\n        expect mock.to.receive.a(1..2)
-  do |m|\n          …\n        end\n\n      The same matching rules apply for arguments
-  as they do for state\n      expectations, so the previous example expects a call
-  to ‹#a› with 1, 2,\n      or the Range 1..2 as an argument on ‹m›.\n\n      If a
-  method must be invoked without any arguments you can use\n      ‹without_arguments›:\n\n
-  \       expect mock.to.receive.a(without_arguments) do |m|\n          …\n        end\n\n
-  \     You can of course use both ‹arg› and actual arguments:\n\n        expect mock.to.receive.a(arg,
-  1, arg) do |m|\n          …\n        end\n\n      The body of the mock method may
-  be given as the block.  Here, calling\n      ‹#a› on ‹m› will give the result ‹1›:\n\n
-  \       expect mock.to.receive.a{ 1 } do |m|\n          …\n        end\n\n      If
-  no body has been given, the result will be a stub object.\n\n      There is a caveat
-  here in that a block can’t yield in Ruby 1.8.  To work\n      around this deficiency
-  you have to use the ‹#yield› method:\n\n        expect mock.to.receive.a.yield(1)
-  do |m|\n          …\n        end\n\n      Any number of values to yield upon successive
-  calls may be given.  The\n      last value given will be used repeatedly when all
-  preceding values have\n      been consumed.  It’s also important to know that values
-  are splatted when\n      they are yielded.\n\n      To simulate an ‹#each›-like
-  method you can use ‹#each›.  The following\n      horrible example should give you
-  an idea of how to use it.\n\n        expect Object.new.to.receive.each.each(1, 2,
-  3) do |o|\n          class << o\n            include Enumerable\n          end\n
-  \         o.inject{ |i, a| i + a }\n        end\n\n      Invocation count expectations
-  can also be set if the default expectation\n      of “at least once” isn’t good
-  enough.  The following expectations are\n      possible\n\n    •   ‹#at_most_once›\n
-  \   •   ‹#once›\n    •   ‹#at_least_once›\n    •   ‹#twice›\n\n      And, for a
-  given ‹N›,\n\n    •   ‹#at_most(N)›\n    •   ‹#exactly(N)›\n    •   ‹#at_least(N)›\n\n
-  \     Method stubs are another useful thing to have in a unit testing\n      framework.
-  \ Sometimes you need to override a method that does something a\n      test shouldn’t
-  do, like access and alter bank accounts.  We can override\n      – stub out – a
-  method by using the ‹#stub› method.  Let’s assume that we\n      have an ‹Account›
-  class that has two methods, ‹#slips› and ‹#total›.\n      ‹#Slips› retrieves the
-  bank slips that keep track of your deposits to the\n      ‹Account› from a database.
-  \ ‹#Total› sums the ‹#slips›.  In the following\n      test we want to make sure
-  that ‹#total› does what it should do without\n      accessing the database.  We
-  therefore stub out ‹#slips› and make it\n      return something that we can easily
-  control.\n\n        expect 6 do |m|\n          account = Account.new\n          stub(account).slips{
-  [1, 2, 3] }\n          account.total\n        end\n\n      As with mock methods,
-  if no body is given, the result will be a stub\n      object.\n\n      To make it
-  easy to create objects with a set of stubbed methods there’s\n      also a convenience
-  method:\n\n        expect 3 do\n          s = stub(:a => 1, :b => 2)\n          s.a
-  + s.b\n        end\n\n      Please note that this makes it impossible to stub a
-  method on a Hash, but\n      you shouldn’t be doing that anyway.  In fact, you should
-  never mock or\n      stub methods on value objects.\n\n§ Integration\n\n    Lookout
-  can be used from Rake¹.  Simply include the following code in\n    your ‹Rakefile›:\n\n
-  \     require 'lookout/rake/tasks'\n\n      Lookout::Rake::Tasks::Test.new\n\n    If
-  the ‹:default› task hasn’t been defined it will be set to depend on the\n    ‹:test›
-  task.\n\n    As an added bonus you can use Lookout’s own gem² tasks:\n\n      Lookout::Rake::Tasks::Gem.new\n\n
-  \   This provides tasks to ‹build›, ‹check›, ‹install›, and ‹push› your gem.\n\n
-  \   To use Lookout together with Vim³, place ‹contrib/rakelookout.vim› in\n    ‹~/.vim/compiler›
-  and add\n\n      compiler rakelookout\n\n    to ‹~/.vim/after/ftplugin/ruby.vim›.
-  \ Executing ‹:make› from inside Vim\n    will now run your tests and an errors and
-  failures can be visited with\n    ‹:cnext›.  Execute ‹:help quickfix› for additional
-  information.\n\n    Another useful addition to your ‹~/.vim/after/ftplugin/ruby.vim›
-  file may\n    be\n\n      nnoremap <buffer> <silent> <Leader>M <Esc>:call <SID>run_test()<CR>\n
-  \     let b:undo_ftplugin .= ' | nunmap <buffer> <Leader>M'\n\n      function! s:run_test()\n
-  \       let test = expand('%')\n        let line = 'LINE=' . line('.')\n        if
-  test =~ '^lib/'\n          let test = substitute(test, '^lib/', 'test/', '')\n          let
-  line = \"\"\n        endif\n        execute 'make' 'TEST=' . shellescape(test) line\n
-  \     endfunction\n\n    Now, pressing ‹<Leader>M› will either run all tests for
-  a given class, if\n    the implementation file is active, or run the test at or
-  just before the\n    cursor, if the test file is active.  This is useful if you’re
-  currently\n    receiving a lot of errors and/or failures and want to focus on those\n
-  \   associated with a specific class or on a specific test.\n\n¹ Read more about
-  Rake at http://rake.rubyforge.org/\n² Get information on RubyGems at http://rubygems.org/\n³
-  Find out more about Vim at http://www.vim.org/\n\n§ Interface Design\n\n    The
-  default output of Lookout can Spartanly be described as Spartan.  If no\n    errors
-  or failures occur, no output is generated.  This is unconventional,\n    as unit
-  testing frameworks tend to dump a lot of information on the user,\n    concerning
-  things such as progress, test count summaries, and flamboyantly\n    colored text
-  telling you that your tests passed.  None of this output is\n    needed.  Your tests
-  should run fast enough to not require progress reports.\n    The lack of output
-  provides you with the same amount of information as\n    reporting success.  Test
-  count summaries are only useful if you’re worried\n    that your tests aren’t being
-  run, but if you worry about that, then\n    providing such output doesn’t really
-  help.  Testing your tests requires\n    something beyond reporting some arbitrary
-  count that you would have to\n    verify by hand anyway.\n\n    When errors or failures
-  do occur, however, the relevant information is\n    output in a format that can
-  easily be parsed by an ‹'errorformat'› for Vim\n    or with {Compilation Mode}¹
-  for Emacs².  Diffs are generated for Strings,\n    Arrays, Hashes, and I/O.\n\n¹
-  Read up on Compilation mode for Emacs at http://www.emacswiki.org/emacs/CompilationMode\n²
-  Visit The GNU Foundation’s Emacs’ software page at http://www.gnu.org/software/emacs/\n\n§
-  External Design\n\n    Let’s now look at some of the points made in the introduction
-  in greater\n    detail.\n\n    Lookout only allows you to set one expectation per
-  test.  If you’re testing\n    behavior with a mock, then only one method-invocation
-  expectation can be\n    set.  If you’re testing state, then only one result can
-  be verified.  It\n    may seem like this would cause unnecessary duplication between
-  tests.\n    While this is certainly a possibility, when you actually begin to try
-  to\n    avoid such duplication you find that you often do so by improving your\n
-  \   interfaces.  This kind of restriction tends to encourage the use of value\n
-  \   objects, which are easy to test, and more focused objects, which require\n    simpler
-  tests, as they have less behavior to test, per method.  By keeping\n    your interfaces
-  focused you’re also keeping your tests focused.\n\n    Keeping your tests focused
-  improves, in itself, test isolation, but let’s\n    look at something that hinders
-  it: setup and teardown methods.  Most unit\n    testing frameworks encourage test
-  fragmentation by providing setup and\n    teardown methods.\n\n    Setup methods
-  create objects and, perhaps, just their behavior for a set of\n    tests.  This
-  means that you have to look in two places to figure out what’s\n    being done in
-  a test.  This may work fine for few methods with simple\n    set-ups, but makes
-  things complicated when the number of tests increases\n    and the set-up is complex.
-  \ Often, each test further adjusts the previously\n    set-up object before performing
-  any verifications, further complicating the\n    process of figuring out what state
-  an object has in a given test.\n\n    Teardown methods clean up after tests, perhaps
-  by removing records from a\n    database or deleting files from the file-system.
-  \ \n\n    The duplication that setup methods and teardown methods hope to remove
-  is\n    better avoided by improving your interfaces.  This can be done by providing\n
-  \   better set-up methods for your objects and using idioms such as {Resource\n
-  \   Acquisition Is Initialization}¹ for guaranteed clean-up, test or no test.\n\n
-  \   By not using setup and teardown methods we keep everything pertinent to a\n
-  \   test in the test itself, thus improving test isolation.  (You also won’t\n    {slow
-  down your tests}² by keeping unnecessary state.)\n\n    Most unit test frameworks
-  also allow you to create arbitrary test helper\n    methods.  Lookout doesn’t.  The
-  same rationale as that that has been\n    crystallized in the preceding paragraphs
-  applies.  If you need helpers\n    you’re interface isn’t good enough.  It really
-  is as simple as that.\n\n    To clarify: there’s nothing inherently wrong with test
-  helper methods, but\n    they should be general enough that they reside in their
-  own library.  The\n    support for mocks in Lookout is provided through a set of
-  test helper\n    methods that make it easier to create mocks than it would have
-  been without\n    them.  Lookout-rack³ is another example of a library providing
-  test helper\n    methods (well, one of method, actually) that are very useful in
-  testing web\n    applications that use Rack⁴.\n\n    A final point at which some
-  unit test frameworks try to fragment tests\n    further is documentation.  These
-  frameworks provide ways of describing the\n    whats and hows of what’s being tested,
-  the rationale being that this will\n    provide documentation of both the test and
-  the code being tested.\n    Describing how a stack data structure is meant to work
-  is a common example.\n    A stack is, however, a rather simple data structure, so
-  such a description\n    provides little, if any, additional information that can’t
-  be extracted\n    from the implementation and its tests themselves.  The implementation
-  and\n    its tests is, in fact, its own best documentation.  Taking the points made\n
-  \   in the previous paragraphs into account, we should already have simple,\n    self-describing,
-  interfaces that have easily understood tests associated\n    with them.  Rationales
-  for the use of a given data structure or\n    system-design design documentation
-  is better suited in separate\n    documentation focused at describing exactly those
-  issues.\n\n¹ Read the Wikipedia entry for Resource Acquisition Is Initialization
-  at\n  http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization\n² Read
-  how 37signals had problems with slow Test::Unit tests at\n  http://37signals.com/svn/posts/2742-the-road-to-faster-tests/\n³
-  Visit the Lookout-rack GitHub project page at\n  http://github.com/now/lookout-rack/\n⁴
-  Visit the Rack Rubyforge project page at\n  http://rack.rubyforge.org/\n\n§ Internal
-  Design\n\n    The internal design of Lookout has had a couple of goals.\n\n  •   As
-  few external dependencies as possible\n  •   As few internal dependencies as possible\n
-  \ •   Internal extensibility provides external extensibility\n  •   As fast load
-  times as possible\n  •   As high a ratio of value objects to mutable objects as
-  possible\n  •   Each object must have a simple, obvious name\n  •   Use mix-ins,
-  not inheritance for shared behavior\n  •   As few responsibilities per object as
-  possible\n  •   Optimizing for speed can only be done when you have all the facts\n\n§
-  External Dependencies\n\n    Lookout used to depend on Mocha for mocks and stubs.
-  \ While benchmarking I\n    noticed that a method in Mocha was taking up more than
-  300 percent of the\n    runtime.  It turned out that Mocha’s method for cleaning
-  up back-traces\n    generated when a mock failed was doing something incredibly
-  stupid:\n\n      backtrace.reject{ |l| Regexp.new(@lib).match(File.expand_path(l))
-  }\n\n    Here ‹@lib› is a ‹String› containing the path to the lib subdirectory in\n
-  \   the Mocha installation directory.  I reported it, provided a patch five\n    days
-  later, then waited.  Nothing happened.  {254 days later}¹, according\n    to {Wolfram
-  Alpha}², half of my patch was, apparently – I say “apparently”,\n    as I received
-  no notification – applied.  By that time I had replaced the\n    whole mocking-and-stubbing
-  subsystem and dropped the dependency.\n\n    Many Ruby developers claim that Ruby
-  and its gems are too fast-moving for\n    normal package-managing systems to keep
-  up.  This is testament to the fact\n    that this isn’t the case and that the real
-  problem is instead related to\n    sloppy practices.\n\n    Please note that I don’t
-  want to single out the Mocha library nor its\n    developers.  I only want to provide
-  an example where relying on external\n    dependencies can be “considered harmful”.\n\n¹
-  See the Wolfram Alpha calculation at http://www.wolframalpha.com/input/?i=days+between+march+17%2C+2010+and+november+26%2C+2010\n²
-  Check out the Wolfram Alpha computational knowledge engine at http://www.wolframalpha.com/\n\n§
-  Internal Dependencies\n\n    Lookout has been designed so as to keep each subsystem
-  independent of any\n    other.  The diff subsystem is, for example, completely decoupled
-  from any\n    other part of the system as a whole and could be moved into its own
-  library\n    at a time where that would be of interest to anyone.  What’s perhaps
-  more\n    interesting is that the diff subsystem is itself very modular.  The data\n
-  \   passes through a set of filters that depends on what kind of diff has been\n
-  \   requested, each filter yielding modified data as it receives it.  If you\n    want
-  to read some rather functional Ruby I can highly recommend looking at\n    the code
-  in the ‹lib/lookout/diff› directory.\n\n    This lookout on the design of the library
-  also makes it easy to extend\n    Lookout.  Lookout-rack was, for example, written
-  in about four hours and\n    about 5 of those 240 minutes were spent on setting
-  up the interface between\n    the two.\n\n§ Optimizing For Speed\n\n    The following
-  paragraph is perhaps a bit personal, but might be interesting\n    nonetheless.\n\n
-  \   I’ve always worried about speed.  The original Expectations library used\n    ‹extend›
-  a lot to add new behavior to objects.  Expectations, for example,\n    used to hold
-  the result of their execution (what we now term “evaluation”)\n    by being extended
-  by a module representing success, failure, or error.  For\n    the longest time
-  I used this same method, worrying about the increased\n    performance cost that
-  creating new objects for results would incur.  I\n    finally came to a point where
-  I felt that the code was so simple and clean\n    that rewriting this part of the
-  code for a benchmark wouldn’t take more\n    than perhaps ten minutes.  Well, ten
-  minutes later I had my results and\n    they confirmed that creating new objects
-  wasn’t harming performance.  I was\n    very pleased.\n\n§ Naming\n\n    I hate
-  low lines (underscores).  I try to avoid them in method names and I\n    always
-  avoid them in file names.  Since the current “best practice” in the\n    Ruby community
-  is to put ‹BeginEndStorage› in a file called\n    ‹begin_end_storage.rb›, I only
-  name constants using a single noun.  This\n    has had the added benefit that classes
-  seem to have acquired less behavior,\n    as using a single noun doesn’t allow you
-  to tack on additional behavior\n    without questioning if it’s really appropriate
-  to do so, given the rather\n    limited range of interpretation for that noun.  It
-  also seems to encourage\n    the creation of value objects, as something named ‹Range›
-  feels a lot more\n    like a value than ‹BeginEndStorage›.  (To reach object-oriented-programming\n
-  \   Nirvana you must achieve complete value.)\n\n\n§ Contributors\n\n    Contributors
-  to the original expectations codebase are mentioned there.  We\n    hope no one
-  on that list feels left out of this list.  Please\n    {let us know}¹ if you do.\n\n
-  \ •   Nikolai Weibull\n\n¹ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues\n\n\n§
-  License\n\n    You may use, copy, and redistribute this library under the same terms¹\n
-  \   as Ruby itself.\n\n¹ Read the Ruby licensing terms at http://www.ruby-lang.org/en/LICENSE.txt\n"
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.2'
+- !ruby/object:Gem::Dependency
+  name: value
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.1'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ~>
+      - !ruby/object:Gem::Version
+        version: '1.1'
+description: |2
+                                  Lookout
+
+    Lookout is a unit testing framework for Ruby¹ that puts your results in
+    focus. Tests (expectations) are written as follows
+
+      expect 2 do
+        1 + 1
+      end
+
+      expect ArgumentError do
+        Integer('1 + 1')
+      end
+
+      expect Array do
+        [1, 2, 3].select{ |i| i % 2 == 0 }
+      end
+
+      expect [2, 4, 6] do
+        [1, 2, 3].map{ |i| i * 2 }
+      end
+
+    Lookout is designed to encourage – force, even – unit testing best practices
+    such as
+
+  •   Setting up only one expectation per test
+  •   Not setting expectations on non-public APIs
+  •   Test isolation
+
+    This is done by
+
+  •   Only allowing one expectation to be set per test
+  •   Providing no (additional) way of accessing private state
+  •   Providing no setup and tear-down methods, nor a method of providing test
+      helpers
+
+    Other important points are
+
+  •   Putting the expected outcome of a test in focus with the steps of the
+      calculation of the actual result only as a secondary concern
+  •   A focus on code readability by providing no mechanism for describing an
+      expectation other than the code in the expectation itself
+  •   A unified syntax for setting up both state-based and behavior-based
+      expectations
+
+    The way Lookout works has been heavily influenced by expectations², by
+    {Jay Fields}³.  The code base was once also heavily based on expectations,
+    based at Subversion {revision 76}⁴.  A lot has happened since then and all of
+    the work past that revision are due to {Nikolai Weibull}⁵.
+
+  ¹ Ruby: http://ruby-lang.org/
+  ² Expectations: http://expectations.rubyforge.org/
+  ³ Jay Fields’s blog: http://blog.jayfields.com/
+  ⁴ Lookout revision 76:
+    https://github.com/now/lookout/commit/537bedf3e5b3eb4b31c066b3266f42964ac35ebe
+  ⁵ Nikolai Weibull’s home page: http://disu.se/
+
+  § Installation
+
+      Install Lookout with
+
+        % gem install lookout
+
+
+  § Usage
+
+      Lookout allows you to set expectations on an object’s state or behavior.
+      We’ll begin by looking at state expectations and then take a look at
+      expectations on behavior.
+
+    § Expectations on State: Literals
+
+        An expectation can be made on the result of a computation:
+
+          expect 2 do
+            1 + 1
+          end
+
+        Most objects, in fact, have their state expectations checked by invoking
+        ‹#==› on the expected value with the result as its argument.
+
+        Checking that a result is within a given range is also simple:
+
+          expect 0.099..0.101 do
+            0.4 - 0.3
+          end
+
+        Here, the more general ‹#===› is being used on the ‹Range›.
+
+    § Regexps
+
+        ‹Strings› of course match against ‹Strings›:
+
+          expect 'ab' do
+            'abc'[0..1]
+          end
+
+        but we can also match a ‹String› against a ‹Regexp›:
+
+          expect %r{a substring} do
+            'a string with a substring'
+          end
+
+        (Note the use of ‹%r{…}› to avoid warnings that will be generated when
+        Ruby parses ‹expect /…/›.)
+
+    § Modules
+
+        Checking that the result includes a certain module is done by expecting the
+        ‹Module›.
+
+          expect Enumerable do
+            []
+          end
+
+        This, due to the nature of Ruby, of course also works for classes (as
+        they are also modules):
+
+          expect String do
+            'a string'
+          end
+
+        This doesn’t hinder us from expecting the actual ‹Module› itself:
+
+          expect Enumerable do
+            Enumerable
+          end
+
+        or the ‹Class›:
+
+          expect String do
+            String
+          end
+
+        for obvious reasons.
+
+        As you may have figured out yourself, this is accomplished by first
+        trying ‹#==› and, if it returns ‹false›, then trying ‹#===› on the
+        expected ‹Module›.  This is also true of ‹Ranges› and ‹Regexps›.
+
+    § Booleans
+
+        Truthfulness is expected with ‹true› and ‹false›:
+
+          expect true do
+            1
+          end
+
+          expect false do
+            nil
+          end
+
+        Results equaling ‹true› or ‹false› are slightly different:
+
+          expect TrueClass do
+            true
+          end
+
+          expect FalseClass do
+            false
+          end
+
+        The rationale for this is that you should only care if the result of a
+        computation evaluates to a value that Ruby considers to be either true or
+        false, not the exact literals ‹true› or ‹false›.
+
+    § IO
+
+        Expecting output on an IO object is also common:
+
+          expect output("abc\ndef\n") do |io|
+            io.puts 'abc', 'def'
+          end
+
+        This can be used to capture the output of a formatter that takes an
+        output object as a parameter.
+
+    § Warnings
+
+        Expecting warnings from code isn’t very common, but should be done:
+
+          expect warning('this is your final one!') do
+            warn 'this is your final one!'
+          end
+
+          expect warning('this is your final one!') do
+            warn '%s:%d: warning: this is your final one!' % [__FILE__, __LINE__]
+          end
+
+        ‹$VERBOSE› is set to ‹true› during the execution of the block, so you
+        don’t need to do so yourself.  If you have other code that depends on the
+        value of $VERBOSE, that can be done with ‹#with_verbose›
+
+          expect nil do
+            with_verbose nil do
+              $VERBOSE
+            end
+          end
+
+    § Errors
+
+        You should always be expecting errors from – and in, but that’s a
+        different story – your code:
+
+          expect ArgumentError do
+            Integer('1 + 1')
+          end
+
+        Often, not only the type of the error, but its description, is important
+        to check:
+
+          expect StandardError.new('message') do
+            raise StandardError.new('message')
+          end
+
+        As with ‹Strings›, ‹Regexps› can be used to check the error description:
+
+          expect StandardError.new(/mess/) do
+            raise StandardError.new('message')
+          end
+
+    § Queries Through Symbols
+
+        Symbols are generally matched against symbols, but as a special case,
+        symbols ending with ‹?› are seen as expectations on the result of query
+        methods on the result of the block, given that the method is of zero
+        arity and that the result isn’t a Symbol itself.  Simply expect a symbol
+        ending with ‹?›:
+
+          expect :empty? do
+            []
+          end
+
+        To expect it’s negation, expect the same symbol beginning with ‹not_›:
+
+          expect :not_nil? do
+            [1, 2, 3]
+          end
+
+        This is the same as
+
+          expect true do
+            [].empty?
+          end
+
+        and
+
+          expect false do
+            [1, 2, 3].empty?
+          end
+
+        but provides much clearer failure messages.  It also makes the
+        expectation’s intent a lot clearer.
+
+    § Queries By Proxy
+
+        There’s also a way to make the expectations of query methods explicit by
+        invoking methods on the result of the block.  For example, to check that
+        the even elements of the Array ‹[1, 2, 3]› include ‹1› you could write
+
+          expect result.to.include? 1 do
+            [1, 2, 3].reject{ |e| e.even? }
+          end
+
+        You could likewise check that the result doesn’t include 2:
+
+          expect result.not.to.include? 2 do
+            [1, 2, 3].reject{ |e| e.even? }
+          end
+
+        This is the same as (and executes a little bit slower than) writing
+
+          expect false do
+            [1, 2, 3].reject{ |e| e.even? }.include? 2
+          end
+
+        but provides much clearer failure messages.  Given that these two last
+        examples would fail, you’d get a message saying “[1, 2, 3]#include?(2)”
+        instead of the terser “true≠false”.  It also clearly separates the actual
+        expectation from the set-up.
+
+        The keyword for this kind of expectations is ‹result›.  This may be
+        followed by any of the methods
+
+      •   ‹#not›
+      •   ‹#to›
+      •   ‹#be›
+      •   ‹#have›
+
+        or any other method you will want to call on the result.  The methods
+        ‹#to›, ‹#be›, and ‹#have› do nothing except improve readability.  The
+        ‹#not› method inverts the expectation.
+
+    § Literal Literals
+
+        If you need to literally check against any of the types of objects
+        otherwise treated specially, that is, any instances of
+
+      •   ‹Module›
+      •   ‹Range›
+      •   ‹Regexp›
+      •   ‹Exception›
+      •   ‹Symbol›, given that it ends with ‹?›
+
+        you can do so by wrapping it in ‹literal(…)›:
+
+          expect literal(:empty?) do
+            :empty?
+          end
+
+        You almost never need to do this, as, for all but symbols, instances will
+        match accordingly as well.
+
+    § Expectations on Behavior
+
+        We expect our objects to be on their best behavior.  Lookout allows you
+        to make sure that they are.
+
+        Reception expectations let us verify that a method is called in the way
+        that we expect it to be:
+
+          expect mock.to.receive.to_str(without_arguments){ '123' } do |o|
+            o.to_str
+          end
+
+        Here, ‹#mock› creates a mock object, an object that doesn’t respond to
+        anything unless you tell it to.  We tell it to expect to receive a call
+        to ‹#to_str› without arguments and have ‹#to_str› return ‹'123'› when
+        called.  The mock object is then passed in to the block so that the
+        expectations placed upon it can be fulfilled.
+
+        Sometimes we only want to make sure that a method is called in the way
+        that we expect it to be, but we don’t care if any other methods are
+        called on the object.  A stub object, created with ‹#stub›, expects any
+        method and returns a stub object that, again, expects any method, and
+        thus fits the bill.
+
+          expect stub.to.receive.to_str(without_arguments){ '123' } do |o|
+            o.to_str if o.convertable?
+          end
+
+        You don’t have to use a mock object to verify that a method is called:
+
+          expect Object.to.receive.name do
+            Object.name
+          end
+
+        As you have figured out by now, the expected method call is set up by
+        calling ‹#receive› after ‹#to›.  ‹#Receive› is followed by a call to the
+        method to expect with any expected arguments.  The body of the expected
+        method can be given as the block to the method.  Finally, an expected
+        invocation count may follow the method.  Let’s look at this formal
+        specification in more detail.
+
+        The expected method arguments may be given in a variety of ways.  Let’s
+        introduce them by giving some examples:
+
+          expect mock.to.receive.a do |m|
+            m.a
+          end
+
+        Here, the method ‹#a› must be called with any number of arguments.  It
+        may be called any number of times, but it must be called at least once.
+
+        If a method must receive exactly one argument, you can use ‹Object›, as
+        the same matching rules apply for arguments as they do for state
+        expectations:
+
+          expect mock.to.receive.a(Object) do |m|
+            m.a 0
+          end
+
+        If a method must receive a specific argument, you can use that argument:
+
+          expect mock.to.receive.a(1..2) do |m|
+            m.a 1
+          end
+
+        Again, the same matching rules apply for arguments as they do for state
+        expectations, so the previous example expects a call to ‹#a› with 1, 2,
+        or the Range 1..2 as an argument on ‹m›.
+
+        If a method must be invoked without any arguments you can use
+        ‹without_arguments›:
+
+          expect mock.to.receive.a(without_arguments) do |m|
+            m.a
+          end
+
+        You can of course use both ‹Object› and actual arguments:
+
+          expect mock.to.receive.a(Object, 2, Object) do |m|
+            m.a nil, 2, '3'
+          end
+
+        The body of the expected method may be given as the block.  Here, calling
+        ‹#a› on ‹m› will give the result ‹1›:
+
+          expect mock.to.receive.a{ 1 } do |m|
+            raise 'not 1' unless m.a == 1
+          end
+
+        If no body has been given, the result will be a stub object.
+
+        To take a block, grab a block parameter and ‹#call› it:
+
+          expect mock.to.receive.a{ |&b| b.call(1) } do |m|
+            j = 0
+            m.a{ |i| j = i }
+            raise 'not 1' unless j == 1
+          end
+
+        To simulate an ‹#each›-like method, ‹#call› the block several times.
+
+        Invocation count expectations can be set if the default expectation of
+        “at least once” isn’t good enough.  The following expectations are
+        possible
+
+      •   ‹#at_most_once›
+      •   ‹#once›
+      •   ‹#at_least_once›
+      •   ‹#twice›
+
+        And, for a given ‹N›,
+
+      •   ‹#at_most(N)›
+      •   ‹#exactly(N)›
+      •   ‹#at_least(N)›
+
+    § Utilities: Stubs
+
+        Method stubs are another useful thing to have in a unit testing
+        framework.  Sometimes you need to override a method that does something a
+        test shouldn’t do, like access and alter bank accounts.  We can override
+        – stub out – a method by using the ‹#stub› method.  Let’s assume that we
+        have an ‹Account› class that has two methods, ‹#slips› and ‹#total›.
+        ‹#Slips› retrieves the bank slips that keep track of your deposits to the
+        ‹Account› from a database.  ‹#Total› sums the ‹#slips›.  In the following
+        test we want to make sure that ‹#total› does what it should do without
+        accessing the database.  We therefore stub out ‹#slips› and make it
+        return something that we can easily control.
+
+          expect 6 do |m|
+            stub(Class.new{
+                   def slips
+                     raise 'database not available'
+                   end
+
+                   def total
+                     slips.reduce(0){ |m, n| m.to_i + n.to_i }
+                   end
+                 }.new, :slips => [1, 2, 3]){ |account| account.total }
+          end
+
+        To make it easy to create objects with a set of stubbed methods there’s
+        also a convenience method:
+
+          expect 3 do
+            s = stub(:a => 1, :b => 2)
+            s.a + s.b
+          end
+
+        This short-hand notation can also be used for the expected value:
+
+          expect stub(:a => 1, :b => 2).to.receive.a do |o|
+            o.a + o.b
+          end
+
+        and also works for mock objects:
+
+          expect mock(:a => 2, :b => 2).to.receive.a do |o|
+            o.a + o.b
+          end
+
+        Blocks are also allowed when defining stub methods:
+
+          expect 3 do
+            s = stub(:a => proc{ |a, b| a + b })
+            s.a(1, 2)
+          end
+
+        If need be, we can stub out a specific method on an object:
+
+          expect 'def' do
+            stub('abc', :to_str => 'def'){ |a| a.to_str }
+          end
+
+        The stub is active during the execution of the block.
+
+    § Overriding Constants
+
+        Sometimes you need to override the value of a constant during the
+        execution of some code.  Use ‹#with_const› to do just that:
+
+          expect 'hello' do
+            with_const 'A::B::C', 'hello' do
+              A::B::C
+            end
+          end
+
+        Here, the constant ‹A::B::C› is set to ‹'hello'› during the execution of
+        the block.  None of the constants ‹A›, ‹B›, and ‹C› need to exist for
+        this to work.  If a constant doesn’t exist it’s created and set to a new,
+        empty, ‹Module›. The value of ‹A::B::C›, if any, is restored after the
+        block returns and any constants that didn’t previously exist are removed.
+
+    § Overriding Environment Variables
+
+        Another thing you often need to control in your tests is the value of
+        environment variables.  Depending on such global values is, of course,
+        not a good practice, but is often unavoidable when working with external
+        libraries.  ‹#With_env› allows you to override the value of environment
+        variables during the execution of a block by giving it a ‹Hash› of
+        key/value pairs where the key is the name of the environment variable and
+        the value is the value that it should have during the execution of that
+        block:
+
+          expect 'hello' do
+            with_env 'INTRO' => 'hello' do
+              ENV['INTRO']
+            end
+          end
+
+        Any overridden values are restored and any keys that weren’t previously a
+        part of the environment are removed when the block returns.
+
+    § Overriding Globals
+
+        You may also want to override the value of a global temporarily:
+
+          expect 'hello' do
+            with_global :$stdout, StringIO.new do
+              print 'hello'
+              $stdout.string
+            end
+          end
+
+        You thus provide the name of the global and a value that it should take
+        during the execution of a block of code.  The block gets passed the
+        overridden value, should you need it:
+
+          expect true do
+            with_global :$stdout, StringIO.new do |overridden|
+              $stdout != overridden
+            end
+          end
+
+  § Integration
+
+      Lookout can be used from Rake¹.  Simply install Lookout-Rake²:
+
+        % gem install lookout-rake
+
+      and add the following code to your Rakefile
+
+        require 'lookout-rake-3.0'
+
+        Lookout::Rake::Tasks::Test.new
+
+      Make sure to read up on using Lookout-Rake for further benefits and
+      customization.
+
+  ¹ Read more about Rake at http://rake.rubyforge.org/
+  ² Get information on Lookout-Rake at http://disu.se/software/lookout-rake/
+
+  § API
+
+      Lookout comes with an API¹ that let’s you create things such as new
+      expected values, difference reports for your types, and so on.
+
+  ¹ See http://disu.se/software/lookout/api/
+
+  § Interface Design
+
+      The default output of Lookout can Spartanly be described as Spartan.  If no
+      errors or failures occur, no output is generated.  This is unconventional,
+      as unit testing frameworks tend to dump a lot of information on the user,
+      concerning things such as progress, test count summaries, and flamboyantly
+      colored text telling you that your tests passed.  None of this output is
+      needed.  Your tests should run fast enough to not require progress reports.
+      The lack of output provides you with the same amount of information as
+      reporting success.  Test count summaries are only useful if you’re worried
+      that your tests aren’t being run, but if you worry about that, then
+      providing such output doesn’t really help.  Testing your tests requires
+      something beyond reporting some arbitrary count that you would have to
+      verify by hand anyway.
+
+      When errors or failures do occur, however, the relevant information is
+      output in a format that can easily be parsed by an ‹'errorformat'› for Vim
+      or with {Compilation Mode}¹ for Emacs².  Diffs are generated for Strings,
+      Arrays, Hashes, and I/O.
+
+  ¹ Read up on Compilation mode for Emacs at http://www.emacswiki.org/emacs/CompilationMode
+  ² Visit The GNU Foundation’s Emacs’ software page at http://www.gnu.org/software/emacs/
+
+  § External Design
+
+      Let’s now look at some of the points made in the introduction in greater
+      detail.
+
+      Lookout only allows you to set one expectation per test.  If you’re testing
+      behavior with a reception expectation, then only one method-invocation
+      expectation can be set.  If you’re testing state, then only one result can
+      be verified.  It may seem like this would cause unnecessary duplication
+      between tests.  While this is certainly a possibility, when you actually
+      begin to try to avoid such duplication you find that you often do so by
+      improving your interfaces.  This kind of restriction tends to encourage the
+      use of value objects, which are easy to test, and more focused objects,
+      which require simpler tests, as they have less behavior to test, per
+      method.  By keeping your interfaces focused you’re also keeping your tests
+      focused.
+
+      Keeping your tests focused improves, in itself, test isolation, but let’s
+      look at something that hinders it: setup and tear-down methods.  Most unit
+      testing frameworks encourage test fragmentation by providing setup and
+      tear-down methods.
+
+      Setup methods create objects and, perhaps, just their behavior for a set of
+      tests.  This means that you have to look in two places to figure out what’s
+      being done in a test.  This may work fine for few methods with simple
+      set-ups, but makes things complicated when the number of tests increases
+      and the set-up is complex.  Often, each test further adjusts the previously
+      set-up object before performing any verifications, further complicating the
+      process of figuring out what state an object has in a given test.
+
+      Tear-down methods clean up after tests, perhaps by removing records from a
+      database or deleting files from the file-system.
+
+      The duplication that setup methods and tear-down methods hope to remove is
+      better avoided by improving your interfaces.  This can be done by providing
+      better set-up methods for your objects and using idioms such as {Resource
+      Acquisition Is Initialization}¹ for guaranteed clean-up, test or no test.
+
+      By not using setup and tear-down methods we keep everything pertinent to a
+      test in the test itself, thus improving test isolation.  (You also won’t
+      {slow down your tests}² by keeping unnecessary state.)
+
+      Most unit test frameworks also allow you to create arbitrary test helper
+      methods.  Lookout doesn’t.  The same rationale as that that has been
+      crystallized in the preceding paragraphs applies.  If you need helpers
+      you’re interface isn’t good enough.  It really is as simple as that.
+
+      To clarify: there’s nothing inherently wrong with test helper methods, but
+      they should be general enough that they reside in their own library.  The
+      support for mocks in Lookout is provided through a set of test helper
+      methods that make it easier to create mocks than it would have been without
+      them.  Lookout-rack³ is another example of a library providing test helper
+      methods (well, one method, actually) that are very useful in testing web
+      applications that use Rack⁴.
+
+      A final point at which some unit test frameworks try to fragment tests
+      further is documentation.  These frameworks provide ways of describing the
+      whats and hows of what’s being tested, the rationale being that this will
+      provide documentation of both the test and the code being tested.
+      Describing how a stack data structure is meant to work is a common example.
+      A stack is, however, a rather simple data structure, so such a description
+      provides little, if any, additional information that can’t be extracted
+      from the implementation and its tests themselves.  The implementation and
+      its tests is, in fact, its own best documentation.  Taking the points made
+      in the previous paragraphs into account, we should already have simple,
+      self-describing, interfaces that have easily understood tests associated
+      with them.  Rationales for the use of a given data structure or
+      system-design design documentation is better suited in separate
+      documentation focused at describing exactly those issues.
+
+  ¹ Read the Wikipedia entry for Resource Acquisition Is Initialization at
+    http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
+  ² Read how 37signals had problems with slow Test::Unit tests at
+    http://37signals.com/svn/posts/2742-the-road-to-faster-tests/
+  ³ Visit the Lookout-rack GitHub project page at
+    http://github.com/now/lookout-rack/
+  ⁴ Visit the Rack Rubyforge project page at
+    http://rack.rubyforge.org/
+
+  § Internal Design
+
+      The internal design of Lookout has had a couple of goals.
+
+    •   As few external dependencies as possible
+    •   As few internal dependencies as possible
+    •   Internal extensibility provides external extensibility
+    •   As fast load times as possible
+    •   As high a ratio of value objects to mutable objects as possible
+    •   Each object must have a simple, obvious name
+    •   Use mix-ins, not inheritance for shared behavior
+    •   As few responsibilities per object as possible
+    •   Optimizing for speed can only be done when you have all the facts
+
+  § External Dependencies
+
+      Lookout used to depend on Mocha for mocks and stubs.  While benchmarking I
+      noticed that a method in Mocha was taking up more than 300 percent of the
+      runtime.  It turned out that Mocha’s method for cleaning up back-traces
+      generated when a mock failed was doing something incredibly stupid:
+
+        backtrace.reject{ |l| Regexp.new(@lib).match(File.expand_path(l)) }
+
+      Here ‹@lib› is a ‹String› containing the path to the lib sub-directory in
+      the Mocha installation directory.  I reported it, provided a patch five
+      days later, then waited.  Nothing happened.  {254 days later}¹, according
+      to {Wolfram Alpha}², half of my patch was, apparently – I say “apparently”,
+      as I received no notification – applied.  By that time I had replaced the
+      whole mocking-and-stubbing subsystem and dropped the dependency.
+
+      Many Ruby developers claim that Ruby and its gems are too fast-moving for
+      normal package-managing systems to keep up.  This is testament to the fact
+      that this isn’t the case and that the real problem is instead related to
+      sloppy practices.
+
+      Please note that I don’t want to single out the Mocha library nor its
+      developers.  I only want to provide an example where relying on external
+      dependencies can be “considered harmful”.
+
+  ¹ See the Wolfram Alpha calculation at http://www.wolframalpha.com/input/?i=days+between+march+17%2C+2010+and+november+26%2C+2010
+  ² Check out the Wolfram Alpha computational knowledge engine at http://www.wolframalpha.com/
+
+  § Internal Dependencies
+
+      Lookout has been designed so as to keep each subsystem independent of any
+      other.  The diff subsystem is, for example, completely decoupled from any
+      other part of the system as a whole and could be moved into its own library
+      at a time where that would be of interest to anyone.  What’s perhaps more
+      interesting is that the diff subsystem is itself very modular.  The data
+      passes through a set of filters that depends on what kind of diff has been
+      requested, each filter yielding modified data as it receives it.  If you
+      want to read some rather functional Ruby I can highly recommend looking at
+      the code in the ‹lib/lookout/diff› directory.
+
+      This lookout on the design of the library also makes it easy to extend
+      Lookout.  Lookout-rack was, for example, written in about four hours and
+      about 5 of those 240 minutes were spent on setting up the interface between
+      the two.
+
+  § Optimizing For Speed
+
+      The following paragraph is perhaps a bit personal, but might be interesting
+      nonetheless.
+
+      I’ve always worried about speed.  The original Expectations library used
+      ‹extend› a lot to add new behavior to objects.  Expectations, for example,
+      used to hold the result of their execution (what we now term “evaluation”)
+      by being extended by a module representing success, failure, or error.  For
+      the longest time I used this same method, worrying about the increased
+      performance cost that creating new objects for results would incur.  I
+      finally came to a point where I felt that the code was so simple and clean
+      that rewriting this part of the code for a benchmark wouldn’t take more
+      than perhaps ten minutes.  Well, ten minutes later I had my results and
+      they confirmed that creating new objects wasn’t harming performance.  I was
+      very pleased.
+
+  § Naming
+
+      I hate low lines (underscores).  I try to avoid them in method names and I
+      always avoid them in file names.  Since the current “best practice” in the
+      Ruby community is to put ‹BeginEndStorage› in a file called
+      ‹begin_end_storage.rb›, I only name constants using a single noun.  This
+      has had the added benefit that classes seem to have acquired less behavior,
+      as using a single noun doesn’t allow you to tack on additional behavior
+      without questioning if it’s really appropriate to do so, given the rather
+      limited range of interpretation for that noun.  It also seems to encourage
+      the creation of value objects, as something named ‹Range› feels a lot more
+      like a value than ‹BeginEndStorage›.  (To reach object-oriented-programming
+      Nirvana you must achieve complete value.)
+
+  § News
+
+    § 3.0.0
+
+        The ‹xml› expectation has been dropped.  It wasn’t documented, didn’t
+        suit very many use cases, and can be better implemented by an external
+        library.
+
+        The ‹arg› argument matcher for mock method arguments has been removed, as
+        it didn’t provide any benefit over using Object.
+
+        The ‹#yield› and ‹#each› methods on stub and mock methods have been
+        removed.  They were slightly weird and their use case can be implemented
+        using block parameters instead.
+
+        The ‹stub› method inside ‹expect› blocks now stubs out the methods during
+        the execution of a provided block instead of during the execution of the
+        whole except block.
+
+        When a mock method is called too many times, this is reported
+        immediately, with a full backtrace.  This makes it easier to pin down
+        what’s wrong with the code.
+
+        Query expectations were added.
+
+        Explicit query expectations were added.
+
+        Fluent boolean expectations, for example, ‹expect nil.to.be.nil?› have
+        been replaced by query expectations (‹expect :nil? do nil end›) and
+        explicit query expectations (‹expect result.to.be.nil? do nil end›).
+        This was done to discourage creating objects as the expected value and
+        creating objects that change during the course of the test.
+
+        The ‹literal› expectation was added.
+
+        Equality (‹#==›) is now checked before “caseity” (‹#===›) for modules,
+        ranges, and regular expressions to match the documentation.
+
+  § Financing
+
+      Currently, most of my time is spent at my day job and in my rather busy
+      private life.  Please motivate me to spend time on this piece of software
+      by donating some of your money to this project.  Yeah, I realize that
+      requesting money to develop software is a bit, well, capitalistic of me.
+      But please realize that I live in a capitalistic society and I need money
+      to have other people give me the things that I need to continue living
+      under the rules of said society.  So, if you feel that this piece of
+      software has helped you out enough to warrant a reward, please PayPal a
+      donation to now@disu.se¹.  Thanks!  Your support won’t go unnoticed!
+
+  ¹ Send a donation:
+    https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now%40disu%2ese&item_name=Nikolai%20Weibull%20Software%20Services
+
+  § Reporting Bugs
+
+      Please report any bugs that you encounter to the {issue tracker}¹.
+
+    ¹ See https://github.com/now/lookout/issues
+
+  § Contributors
+
+      Contributors to the original expectations codebase are mentioned there.  We
+      hope no one on that list feels left out of this list.  Please
+      {let us know}¹ if you do.
+
+    •   Nikolai Weibull
+
+  ¹ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues
+
+  § License
+
+      You may use, copy, and redistribute this library under the same terms¹
+      as Ruby itself.
+
+  ¹ Read the Ruby licensing terms at http://www.ruby-lang.org/en/LICENSE.txt
 email: now@bitwi.se
 executables: []
 extensions: []
 extra_rdoc_files: []
 files:
-- lib/lookout/aphonic.rb
-- lib/lookout/diff/algorithms/difflib/position/to.rb
-- lib/lookout/diff/algorithms/difflib/position.rb
-- lib/lookout/diff/algorithms/difflib.rb
-- lib/lookout/diff/algorithms.rb
-- lib/lookout/diff/formats/hash.rb
-- lib/lookout/diff/formats/inline.rb
-- lib/lookout/diff/formats/unified.rb
-- lib/lookout/diff/formats.rb
-- lib/lookout/diff/group.rb
-- lib/lookout/diff/groups.rb
-- lib/lookout/diff/match.rb
-- lib/lookout/diff/operation.rb
-- lib/lookout/diff/operations/delete.rb
-- lib/lookout/diff/operations/equal.rb
-- lib/lookout/diff/operations/insert.rb
-- lib/lookout/diff/operations/replace.rb
-- lib/lookout/diff/operations.rb
-- lib/lookout/diff/range.rb
-- lib/lookout/diff.rb
-- lib/lookout/equalities/array.rb
-- lib/lookout/equalities/boolean.rb
-- lib/lookout/equalities/hash.rb
-- lib/lookout/equalities/include.rb
-- lib/lookout/equalities/object.rb
-- lib/lookout/equalities/output.rb
-- lib/lookout/equalities/standarderror.rb
-- lib/lookout/equalities/string.rb
-- lib/lookout/equalities/warning.rb
-- lib/lookout/equalities.rb
-- lib/lookout/equality.rb
-- lib/lookout/expectation.rb
-- lib/lookout/expectations/behavior.rb
-- lib/lookout/expectations/line.rb
-- lib/lookout/expectations/state/warning.rb
-- lib/lookout/expectations/state.rb
-- lib/lookout/expectations.rb
-- lib/lookout/mock/method/arguments/any.rb
-- lib/lookout/mock/method/arguments/anything.rb
-- lib/lookout/mock/method/arguments/list.rb
-- lib/lookout/mock/method/arguments/none.rb
-- lib/lookout/mock/method/arguments/one.rb
-- lib/lookout/mock/method/arguments.rb
-- lib/lookout/mock/method/calls/class.rb
-- lib/lookout/mock/method/calls/exactly.rb
-- lib/lookout/mock/method/calls/instance.rb
-- lib/lookout/mock/method/calls/lower.rb
-- lib/lookout/mock/method/calls/upper.rb
-- lib/lookout/mock/method/calls.rb
-- lib/lookout/mock/method.rb
-- lib/lookout/mock/methods.rb
-- lib/lookout/mock/object.rb
-- lib/lookout/mock.rb
-- lib/lookout/object.rb
-- lib/lookout/output.rb
-- lib/lookout/rake/tasks/gem.rb
-- lib/lookout/rake/tasks/tags.rb
-- lib/lookout/rake/tasks/test/loader.rb
-- lib/lookout/rake/tasks/test.rb
-- lib/lookout/rake/tasks.rb
-- lib/lookout/recorder/not.rb
-- lib/lookout/recorder/tape.rb
-- lib/lookout/recorder.rb
-- lib/lookout/recorders/reception.rb
-- lib/lookout/recorders/state.rb
-- lib/lookout/recorders.rb
-- lib/lookout/result.rb
-- lib/lookout/results/error/exception/backtrace.rb
-- lib/lookout/results/error/exception.rb
-- lib/lookout/results/error.rb
-- lib/lookout/results/failure.rb
-- lib/lookout/results/failures/behavior.rb
-- lib/lookout/results/failures/state.rb
-- lib/lookout/results/failures.rb
-- lib/lookout/results/fulfilled.rb
-- lib/lookout/results/unsuccessful.rb
-- lib/lookout/results.rb
-- lib/lookout/runners/console.rb
-- lib/lookout/runners/trackers/failure.rb
-- lib/lookout/runners/trackers.rb
-- lib/lookout/runners.rb
-- lib/lookout/stub/method.rb
-- lib/lookout/stub/methods.rb
-- lib/lookout/stub/object.rb
-- lib/lookout/stub.rb
-- lib/lookout/ui/console.rb
-- lib/lookout/ui/silent.rb
-- lib/lookout/ui.rb
-- lib/lookout/version.rb
-- lib/lookout/warning.rb
-- lib/lookout/xml.rb
-- lib/lookout.rb
+- lib/lookout-3.0/object.rb
+- lib/lookout-3.0/aphonic.rb
+- lib/lookout-3.0/actual.rb
+- lib/lookout-3.0/actual/method.rb
+- lib/lookout-3.0/actual/not.rb
+- lib/lookout-3.0/actual/not/method.rb
+- lib/lookout-3.0/diff.rb
+- lib/lookout-3.0/diff/slice.rb
+- lib/lookout-3.0/diff/algorithms.rb
+- lib/lookout-3.0/diff/algorithms/difflib.rb
+- lib/lookout-3.0/diff/algorithms/difflib/position.rb
+- lib/lookout-3.0/diff/algorithms/difflib/position/new.rb
+- lib/lookout-3.0/diff/formats.rb
+- lib/lookout-3.0/diff/formats/inline.rb
+- lib/lookout-3.0/diff/formats/set.rb
+- lib/lookout-3.0/diff/formats/unified.rb
+- lib/lookout-3.0/diff/group.rb
+- lib/lookout-3.0/diff/groups.rb
+- lib/lookout-3.0/diff/match.rb
+- lib/lookout-3.0/diff/operation.rb
+- lib/lookout-3.0/diff/operations.rb
+- lib/lookout-3.0/diff/operations/delete.rb
+- lib/lookout-3.0/diff/operations/copy.rb
+- lib/lookout-3.0/diff/operations/insert.rb
+- lib/lookout-3.0/diff/operations/replace.rb
+- lib/lookout-3.0/difference.rb
+- lib/lookout-3.0/difference/object.rb
+- lib/lookout-3.0/difference/array.rb
+- lib/lookout-3.0/difference/exception.rb
+- lib/lookout-3.0/difference/hash.rb
+- lib/lookout-3.0/difference/range.rb
+- lib/lookout-3.0/difference/lookout.rb
+- lib/lookout-3.0/difference/lookout/actual.rb
+- lib/lookout-3.0/difference/lookout/actual/method.rb
+- lib/lookout-3.0/difference/lookout/actual/not.rb
+- lib/lookout-3.0/difference/lookout/actual/not/method.rb
+- lib/lookout-3.0/difference/lookout/output.rb
+- lib/lookout-3.0/difference/lookout/reception.rb
+- lib/lookout-3.0/difference/lookout/warning.rb
+- lib/lookout-3.0/difference/module.rb
+- lib/lookout-3.0/difference/regexp.rb
+- lib/lookout-3.0/difference/string.rb
+- lib/lookout-3.0/difference/symbol.rb
+- lib/lookout-3.0/encode.rb
+- lib/lookout-3.0/exception.rb
+- lib/lookout-3.0/exception/backtrace.rb
+- lib/lookout-3.0/exception/unknown.rb
+- lib/lookout-3.0/expect.rb
+- lib/lookout-3.0/expect/object.rb
+- lib/lookout-3.0/expect/object/context.rb
+- lib/lookout-3.0/expect/classes.rb
+- lib/lookout-3.0/expect/classes/exception.rb
+- lib/lookout-3.0/expect/exception.rb
+- lib/lookout-3.0/expected.rb
+- lib/lookout-3.0/expected/object.rb
+- lib/lookout-3.0/expected/array.rb
+- lib/lookout-3.0/expected/classes.rb
+- lib/lookout-3.0/expected/classes/exception.rb
+- lib/lookout-3.0/expected/exception.rb
+- lib/lookout-3.0/expected/falseclass.rb
+- lib/lookout-3.0/expected/hash.rb
+- lib/lookout-3.0/expected/lookout.rb
+- lib/lookout-3.0/expected/lookout/actual.rb
+- lib/lookout-3.0/expected/lookout/actual/method.rb
+- lib/lookout-3.0/expected/lookout/actual/not.rb
+- lib/lookout-3.0/expected/lookout/actual/not/method.rb
+- lib/lookout-3.0/expected/lookout/output.rb
+- lib/lookout-3.0/expected/lookout/reception.rb
+- lib/lookout-3.0/expected/lookout/warning.rb
+- lib/lookout-3.0/expected/module.rb
+- lib/lookout-3.0/expected/range.rb
+- lib/lookout-3.0/expected/regexp.rb
+- lib/lookout-3.0/expected/string.rb
+- lib/lookout-3.0/expected/symbol.rb
+- lib/lookout-3.0/expected/trueclass.rb
+- lib/lookout-3.0/expectations.rb
+- lib/lookout-3.0/expectations/context.rb
+- lib/lookout-3.0/inspect.rb
+- lib/lookout-3.0/interfaces.rb
+- lib/lookout-3.0/interfaces/commandline.rb
+- lib/lookout-3.0/literal.rb
+- lib/lookout-3.0/stub.rb
+- lib/lookout-3.0/mock.rb
+- lib/lookout-3.0/output.rb
+- lib/lookout-3.0/plugins.rb
+- lib/lookout-3.0/reception.rb
+- lib/lookout-3.0/reception/arguments.rb
+- lib/lookout-3.0/reception/arguments/any.rb
+- lib/lookout-3.0/reception/arguments/error.rb
+- lib/lookout-3.0/reception/arguments/list.rb
+- lib/lookout-3.0/reception/arguments/none.rb
+- lib/lookout-3.0/reception/error.rb
+- lib/lookout-3.0/object/not.rb
+- lib/lookout-3.0/object/not/receive.rb
+- lib/lookout-3.0/object/to.rb
+- lib/lookout-3.0/object/to/receive.rb
+- lib/lookout-3.0/result.rb
+- lib/lookout-3.0/results.rb
+- lib/lookout-3.0/results/error.rb
+- lib/lookout-3.0/results/failure.rb
+- lib/lookout-3.0/results/success.rb
+- lib/lookout-3.0/warning.rb
+- lib/lookout-3.0.rb
+- lib/lookout-3.0/version.rb
+- test/unit/lookout-3.0/object.rb
+- test/unit/lookout-3.0/aphonic.rb
+- test/unit/lookout-3.0/actual.rb
+- test/unit/lookout-3.0/actual/method.rb
+- test/unit/lookout-3.0/actual/not.rb
+- test/unit/lookout-3.0/actual/not/method.rb
+- test/unit/lookout-3.0/diff.rb
+- test/unit/lookout-3.0/diff/slice.rb
+- test/unit/lookout-3.0/diff/algorithms.rb
+- test/unit/lookout-3.0/diff/algorithms/difflib.rb
+- test/unit/lookout-3.0/diff/algorithms/difflib/position.rb
+- test/unit/lookout-3.0/diff/algorithms/difflib/position/new.rb
+- test/unit/lookout-3.0/diff/formats.rb
+- test/unit/lookout-3.0/diff/formats/inline.rb
+- test/unit/lookout-3.0/diff/formats/set.rb
+- test/unit/lookout-3.0/diff/formats/unified.rb
+- test/unit/lookout-3.0/diff/group.rb
+- test/unit/lookout-3.0/diff/groups.rb
+- test/unit/lookout-3.0/diff/match.rb
+- test/unit/lookout-3.0/diff/operation.rb
+- test/unit/lookout-3.0/diff/operations.rb
+- test/unit/lookout-3.0/diff/operations/delete.rb
+- test/unit/lookout-3.0/diff/operations/copy.rb
+- test/unit/lookout-3.0/diff/operations/insert.rb
+- test/unit/lookout-3.0/diff/operations/replace.rb
+- test/unit/lookout-3.0/difference.rb
+- test/unit/lookout-3.0/difference/object.rb
+- test/unit/lookout-3.0/difference/array.rb
+- test/unit/lookout-3.0/difference/exception.rb
+- test/unit/lookout-3.0/difference/hash.rb
+- test/unit/lookout-3.0/difference/range.rb
+- test/unit/lookout-3.0/difference/lookout.rb
+- test/unit/lookout-3.0/difference/lookout/actual.rb
+- test/unit/lookout-3.0/difference/lookout/actual/method.rb
+- test/unit/lookout-3.0/difference/lookout/actual/not.rb
+- test/unit/lookout-3.0/difference/lookout/actual/not/method.rb
+- test/unit/lookout-3.0/difference/lookout/output.rb
+- test/unit/lookout-3.0/difference/lookout/reception.rb
+- test/unit/lookout-3.0/difference/lookout/warning.rb
+- test/unit/lookout-3.0/difference/module.rb
+- test/unit/lookout-3.0/difference/regexp.rb
+- test/unit/lookout-3.0/difference/string.rb
+- test/unit/lookout-3.0/difference/symbol.rb
+- test/unit/lookout-3.0/encode.rb
+- test/unit/lookout-3.0/exception.rb
+- test/unit/lookout-3.0/exception/backtrace.rb
+- test/unit/lookout-3.0/exception/unknown.rb
+- test/unit/lookout-3.0/expect.rb
+- test/unit/lookout-3.0/expect/object.rb
+- test/unit/lookout-3.0/expect/object/context.rb
+- test/unit/lookout-3.0/expect/classes.rb
+- test/unit/lookout-3.0/expect/classes/exception.rb
+- test/unit/lookout-3.0/expect/exception.rb
+- test/unit/lookout-3.0/expected.rb
+- test/unit/lookout-3.0/expected/object.rb
+- test/unit/lookout-3.0/expected/array.rb
+- test/unit/lookout-3.0/expected/classes.rb
+- test/unit/lookout-3.0/expected/classes/exception.rb
+- test/unit/lookout-3.0/expected/exception.rb
+- test/unit/lookout-3.0/expected/falseclass.rb
+- test/unit/lookout-3.0/expected/hash.rb
+- test/unit/lookout-3.0/expected/lookout.rb
+- test/unit/lookout-3.0/expected/lookout/actual.rb
+- test/unit/lookout-3.0/expected/lookout/actual/method.rb
+- test/unit/lookout-3.0/expected/lookout/actual/not.rb
+- test/unit/lookout-3.0/expected/lookout/actual/not/method.rb
+- test/unit/lookout-3.0/expected/lookout/output.rb
+- test/unit/lookout-3.0/expected/lookout/reception.rb
+- test/unit/lookout-3.0/expected/lookout/warning.rb
+- test/unit/lookout-3.0/expected/module.rb
+- test/unit/lookout-3.0/expected/range.rb
+- test/unit/lookout-3.0/expected/regexp.rb
+- test/unit/lookout-3.0/expected/string.rb
+- test/unit/lookout-3.0/expected/symbol.rb
+- test/unit/lookout-3.0/expected/trueclass.rb
+- test/unit/lookout-3.0/expectations.rb
+- test/unit/lookout-3.0/expectations/context.rb
+- test/unit/lookout-3.0/inspect.rb
+- test/unit/lookout-3.0/interfaces.rb
+- test/unit/lookout-3.0/interfaces/commandline.rb
+- test/unit/lookout-3.0/literal.rb
+- test/unit/lookout-3.0/stub.rb
+- test/unit/lookout-3.0/mock.rb
+- test/unit/lookout-3.0/output.rb
+- test/unit/lookout-3.0/plugins.rb
+- test/unit/lookout-3.0/reception.rb
+- test/unit/lookout-3.0/reception/arguments.rb
+- test/unit/lookout-3.0/reception/arguments/any.rb
+- test/unit/lookout-3.0/reception/arguments/error.rb
+- test/unit/lookout-3.0/reception/arguments/list.rb
+- test/unit/lookout-3.0/reception/arguments/none.rb
+- test/unit/lookout-3.0/reception/error.rb
+- test/unit/lookout-3.0/object/not.rb
+- test/unit/lookout-3.0/object/not/receive.rb
+- test/unit/lookout-3.0/object/to.rb
+- test/unit/lookout-3.0/object/to/receive.rb
+- test/unit/lookout-3.0/result.rb
+- test/unit/lookout-3.0/results.rb
+- test/unit/lookout-3.0/results/error.rb
+- test/unit/lookout-3.0/results/failure.rb
+- test/unit/lookout-3.0/results/success.rb
+- test/unit/lookout-3.0/warning.rb
+- test/unit/lookout-3.0.rb
+- test/unit/lookout-3.0/version.rb
 - test/unit/examples.rb
-- test/unit/lookout/diff/algorithms/difflib/position/to.rb
-- test/unit/lookout/diff/algorithms/difflib/position.rb
-- test/unit/lookout/diff/algorithms/difflib.rb
-- test/unit/lookout/diff/formats/inline.rb
-- test/unit/lookout/diff/formats/unified.rb
-- test/unit/lookout/diff/group.rb
-- test/unit/lookout/diff/groups.rb
-- test/unit/lookout/diff/match.rb
-- test/unit/lookout/diff/operations/delete.rb
-- test/unit/lookout/diff/operations/equal.rb
-- test/unit/lookout/diff/operations/insert.rb
-- test/unit/lookout/diff/operations/replace.rb
-- test/unit/lookout/diff/operations.rb
-- test/unit/lookout/diff/range.rb
-- test/unit/lookout/diff.rb
-- test/unit/lookout/equality.rb
-- test/unit/lookout/expectation.rb
-- test/unit/lookout/expectations/behavior.rb
-- test/unit/lookout/expectations/line.rb
-- test/unit/lookout/expectations/state.rb
-- test/unit/lookout/expectations.rb
-- test/unit/lookout/mock/method/arguments/any.rb
-- test/unit/lookout/mock/method/arguments.rb
-- test/unit/lookout/mock/method.rb
-- test/unit/lookout/recorder.rb
-- test/unit/lookout/results/error/exception/backtrace.rb
-- test/unit/lookout/results/error.rb
-- test/unit/lookout/results/failures/behavior.rb
-- test/unit/lookout/results/failures/state.rb
-- test/unit/lookout/results/fulfilled.rb
-- test/unit/lookout/results/unsuccessful.rb
-- test/unit/lookout/results.rb
-- test/unit/lookout/runners/console.rb
-- test/unit/lookout/runners/trackers/failure.rb
-- test/unit/lookout/stub/method.rb
-- test/unit/lookout/stub/methods.rb
-- test/unit/lookout/ui/console.rb
-- test/unit/lookout/xml.rb
-- test/unit/lookout.rb
 - README
 - Rakefile
-homepage: http://github.com/now/lookout
+homepage: https://github.com/now/lookout
 licenses: []
 metadata: {}
 post_install_message: 
@@ -480,21 +1185,19 @@ rdoc_options: []
 require_paths:
 - lib
 required_ruby_version: !ruby/object:Gem::Requirement
-  none: false
   requirements:
-  - - ! '>='
+  - - '>='
     - !ruby/object:Gem::Version
       version: '0'
 required_rubygems_version: !ruby/object:Gem::Requirement
-  none: false
   requirements:
-  - - ! '>='
+  - - '>='
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 1.8.10
+rubygems_version: 2.0.0
 signing_key: 
 specification_version: 4
-summary: Lookout is a lightweight unit testing framework.
+summary: focus.
 test_files: []