lookout 2.1.4 → 2.2.0

data/test/unit/lookout/expectations.rb

@@ -1,18 +1,6 @@
 # -*- coding: utf-8 -*-
 
 Expectations do
-  expect true do
-    Lookout::Results::Unsuccessful.new.tap{ |results|
-      Lookout::Expectations.new(results)
-    }.succeeded?
-  end
-
-  expect false do
-    Lookout::Results::Unsuccessful.new.tap{ |results|
-      Lookout::Expectations.new(results).expect(1){ 2 }
-    }.succeeded?
-  end
-
   expect 3 do
     Lookout::Results::Unsuccessful.new.tap{ |results|
       Lookout::Expectations.new(results).
@@ -22,32 +10,6 @@ Expectations do
     }.count
   end
 
-  expect 1 do
-    Lookout::Results::Unsuccessful.new.tap{ |results|
-      expectations = Lookout::Expectations.new(results, __LINE__ + 1)
-      expectations.expect(1){ 2 }
-      expectations.expect(1){ 2 }
-    }.count
-  end
-
-  expect 1 do
-    Lookout::Results::Unsuccessful.new.tap{ |results|
-      expectations = Lookout::Expectations.new(results, __LINE__ + 1)
-      expectations.expect(1){ 2 }
-      expectations.expect(1){ 2 }
-      expectations.flush
-    }.count
-  end
-
-  expect 1 do
-    Lookout::Results::Unsuccessful.new.tap{ |results|
-      expectations = Lookout::Expectations.new(results, __LINE__ + 2)
-      expectations.expect(1){ 2 }
-      expectations.expect(1){ 2 }
-      expectations.flush
-    }.count
-  end
-
   expect __LINE__ + 2 do
     Lookout::Results::Unsuccessful.new.tap{ |results|
       Lookout::Expectations.new(results).expect(1){ 2 }

data/test/unit/lookout/expectations/line.rb

@@ -0,0 +1,29 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect 1 do
+    Lookout::Results::Unsuccessful.new.tap{ |results|
+      expectations = Lookout::Expectations::Line.new(__LINE__ + 1, results)
+      expectations.expect(1){ 2 }
+      expectations.expect(1){ 2 }
+    }.count
+  end
+
+  expect 1 do
+    Lookout::Results::Unsuccessful.new.tap{ |results|
+      expectations = Lookout::Expectations::Line.new(__LINE__ + 1, results)
+      expectations.expect(1){ 2 }
+      expectations.expect(1){ 2 }
+      expectations.flush
+    }.count
+  end
+
+  expect 1 do
+    Lookout::Results::Unsuccessful.new.tap{ |results|
+      expectations = Lookout::Expectations::Line.new(__LINE__ + 2, results)
+      expectations.expect(1){ 2 }
+      expectations.expect(1){ 2 }
+      expectations.flush
+    }.count
+  end
+end

data/test/unit/lookout/results/error/exception/backtrace.rb

@@ -0,0 +1,20 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect "\tfrom 1
+\tfrom 2
+\tfrom 3
+\tfrom 4
+\tfrom 5
+\tfrom 6
+\tfrom 7
+\tfrom 8
+\t ... 6 levels ...
+\tfrom A
+\tfrom B
+\tfrom C
+\tfrom D
+\tfrom E" do
+    Lookout::Results::Error::Exception::Backtrace.new(%w[1 2 3 4 5 6 7 8 a b c d e f A B C D E], true, false).to_s
+  end
+end

data/test/unit/lookout/results/unsuccessful.rb

@@ -6,19 +6,4 @@ Expectations do
     results << Lookout::Results::Fulfilled.new(nil, 0)
     results.count
   end
-
-  expect Lookout::Results::Unsuccessful.new.not.to.have.succeeded? do |results|
-    results << Lookout::Results::Failures::State.new(nil, 0, nil)
-    results << Lookout::Results::Fulfilled.new(nil, 0)
-  end
-
-  expect Lookout::Results::Unsuccessful.new.not.to.have.succeeded? do |results|
-    results << Lookout::Results::Failures::Behavior.new(nil, 0, nil)
-    results << Lookout::Results::Fulfilled.new(nil, 0)
-  end
-
-  expect Lookout::Results::Unsuccessful.new.to.have.succeeded? do |results|
-    results << Lookout::Results::Fulfilled.new(nil, 0)
-    results << Lookout::Results::Fulfilled.new(nil, 0)
-  end
 end

data/test/unit/lookout/runners/trackers/failure.rb

@@ -0,0 +1,30 @@
+# -*- coding: utf-8 -*-
+
+Expectations do
+  expect false do
+    Lookout::Runners::Trackers::Failure.new(Lookout::Results.new).failed?
+  end
+
+  expect true do
+    results = Lookout::Results.new
+    failed = Lookout::Runners::Trackers::Failure.new(results)
+    results << Lookout::Results::Failures::State.new(nil, 0, nil)
+    failed.failed?
+  end
+
+  expect true do
+    results = Lookout::Results.new
+    failed = Lookout::Runners::Trackers::Failure.new(results)
+    results << Lookout::Results::Failures::State.new(nil, 0, nil)
+    results << Lookout::Results::Fulfilled.new(nil, 0)
+    failed.failed?
+  end
+
+  expect true do
+    results = Lookout::Results.new
+    failed = Lookout::Runners::Trackers::Failure.new(results)
+    results << Lookout::Results::Fulfilled.new(nil, 0)
+    results << Lookout::Results::Failures::State.new(nil, 0, nil)
+    failed.failed?
+  end
+end

data/test/unit/lookout/ui/{formatters/exception.rb → console.rb}

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

metadata

@@ -1,509 +1,498 @@
---- !ruby/object:Gem::Specification 
+--- !ruby/object:Gem::Specification
 name: lookout
-version: !ruby/object:Gem::Version 
-  hash: 3
-  prerelease: false
-  segments: 
-  - 2
-  - 1
-  - 4
-  version: 2.1.4
+version: !ruby/object:Gem::Version
+  version: 2.2.0
+  prerelease: 
 platform: ruby
-authors: 
+authors:
 - Nikolai Weibull
 autorequire: 
 bindir: bin
 cert_chain: []
-
-date: 2011-07-26 00:00:00 +02:00
-default_executable: 
-dependencies: 
-- !ruby/object:Gem::Dependency 
+date: 2011-10-14 00:00:00.000000000 Z
+dependencies:
+- !ruby/object:Gem::Dependency
   name: yard
-  prerelease: false
-  requirement: &id001 !ruby/object:Gem::Requirement 
+  requirement: &14599272 !ruby/object:Gem::Requirement
     none: false
-    requirements: 
+    requirements:
     - - ~>
-      - !ruby/object:Gem::Version 
-        hash: 7
-        segments: 
-        - 0
-        - 6
-        - 0
+      - !ruby/object:Gem::Version
         version: 0.6.0
   type: :development
-  version_requirements: *id001
-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 \xE2\x80\x93 force, even \xE2\x80\x93 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 [Jay\n\
-  Fields][].  The code base was once also heavily based on [expectations],\n\
-  based at Subversion [revision r76][].  A lot has happened since then and all of the\n\
-  work past that revision are due to [Nikolai Weibull][].\n\n\
-  [expectations]: http://expectations.rubyforge.org\n\
-  [Jay Fields]: http://blog.jayfields.com\n\
-  [revision r76]: https://github.com/now/lookout/commit/537bedf3e5b3eb4b31c066b3266f42964ac35ebe\n\
-  [Nikolai Weibull]: http://bitwi.se\n\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\xE2\x80\x99s state or behavior.  We\xE2\x80\x99ll\n\
-  begin by looking at state expectations and then take a look at expectations on\n\
-  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\
-  (Please note the use of `%r{\xE2\x80\xA6}` to avoid warnings that will be generated when\n\
-  Ruby parses `expect /\xE2\x80\xA6/`.)\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 they are\n\
-  also modules):\n\n    expect String do\n      'a string'\n    end\n\n\
-  This doesn\xE2\x80\x99t 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 trying\n\
-  `#==` and, if it returns `false`, then trying `#===` on the expected `Module`.\n\
-  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 output\n\
-  object as a parameter.\n\n\
-  You should always be expecting errors from \xE2\x80\x93 and in, but that\xE2\x80\x99s a different\n\
-  story \xE2\x80\x93 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 to\n\
-  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\xE2\x80\x99s built-in error classes have slightly complicated\n\
-  behavior and will not allow you to pass a `Regexp` as a parameter.  `NameError`\n\
-  is such a class.  This may warrant further investigation into whether or not\n\
-  this is a bug, but I\xE2\x80\x99ll leave that up to the reader to decide.)\n\n\
-  Lookout further provides a fluent way of setting up expectations on boolean\n\
-  results.  An object can \xE2\x80\x9Cbe\xE2\x80\x9D\n\n    expect Class.new{ attr_accessor :running; }.new.to.be.running do |process|\n      process.running = true\n    end\n\n\
-  or \xE2\x80\x9Cnot be\xE2\x80\x9D\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 \xE2\x80\x9Chave\xE2\x80\x9D\n\n  expect Class.new{ attr_accessor :finished; }.new.to.have.finished do |process|\n    process.finished = true\n  end\n\n\
-  or \xE2\x80\x9Cnot have\xE2\x80\x9D\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 \xE2\x80\x9Cis\xE2\x80\x9D or \xE2\x80\x9Chas\xE2\x80\x9D 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 may\n\
-  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 alternatives\n\
-  that follow it in the list.  `#Be` and `#Have` must be followed by a call to a\n\
-  method.\n\n\
-  ### Expectations on Behavior ###\n\n\
-  We expect our objects to be on their best behavior.  Lookout allows you to make\n\
-  sure that they are.\n\n\
-  Mocks let use verify that a method is called in the way that we expect it to\n\
-  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\xE2\x80\x99t respond to\n\
-  anything unless you tell it to.  We tell it to expect to receive a call to\n\
-  `#dail` with `'2125551212'` as its formal argument, and we expect it to receive\n\
-  it twice.  The mock object is then passed in to the block so that the\n\
-  expectations placed upon it can be fulfilled.\n\n\
-  Sometimes we only want to make sure that a method is called in the way that we\n\
-  expect it to be, but we don\xE2\x80\x99t care if any other methods are called on the\n\
-  object.  A stub object, created with `#stub`, expects any method and returns a\n\
-  stub object that, again, expects any method, and 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\
-  and 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\xE2\x80\x99t 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 calling\n\
-  `#receive` after `#to`.  `#Receive` is followed by a call to the method to\n\
-  expect with any expected arguments.  The body of the mocked method can be given\n\
-  as the block to the method.  Finally, an expected invocation count may follow\n\
-  the method.  Let\xE2\x80\x99s look at this formal specification in more detail.\n\n\
-  The expected method arguments may be given in a variety of ways.  Let\xE2\x80\x99s\n\
-  introduce them by giving some examples:\n\n    expect mock.to.receive.a do |m|\n      \xE2\x80\xA6\n    end\n\n\
-  Here, the method `#a` must be called with any number of arguments.  It may be\n\
-  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      \xE2\x80\xA6\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      \xE2\x80\xA6\n    end\n\n\
-  The same matching rules apply for arguments as they do for state expectations,\n\
-  so the previous example expects a call to `#a` with 1, 2, or the Range 1..2 as\n\
-  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      \xE2\x80\xA6\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      \xE2\x80\xA6\n    end\n\n\
-  The body of the mock method may be given as the block.  Here, calling `#a` on\n\
-  `m` will give the result `1`:\n\n    expect mock.to.receive.a{ 1 } do |m|\n      \xE2\x80\xA6\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\xE2\x80\x99t yield in Ruby 1.8.  To work around\n\
-  this deficiency you have to use the `#yield` method:\n\n    expect mock.to.receive.a.yield(1) do |m|\n      \xE2\x80\xA6\n    end\n\n\
-  Any number of values to yield upon successive calls may be given.  The last\n\
-  value given will be used repeatedly when all preceding values have been\n\
-  consumed.  It\xE2\x80\x99s also important to know that values are splatted when they are\n\
-  yielded.\n\n\
-  To simulate an `#each`-like method you can use `#each`.  The following horrible\n\
-  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 of\n\
-  \xE2\x80\x9Cat least once\xE2\x80\x9D isn\xE2\x80\x99t good enough.  The following expectations are 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 framework.\n\
-  Sometimes you need to override a method that does something a test shouldn\xE2\x80\x99t\n\
-  do, like access and alter bank accounts.  We can override \xE2\x80\x93 stub out \xE2\x80\x93 a method\n\
-  by using the `#stub` method.  Let\xE2\x80\x99s assume that we have an `Account` class that\n\
-  has two methods, `#slips` and `#total`.  `#Slips` retrieves the bank slips that\n\
-  keep track of your deposits to the `Account` from a database.  `#Total` sums\n\
-  the `#slips`.  In the following test we want to make sure that `#total` does\n\
-  what it should do without accessing the database.  We therefore stub out\n\
-  `#slips` and make it 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 object.\n\n\
-  To make it easy to create objects with a set of stubbed methods there\xE2\x80\x99s also a\n\
-  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 you\n\
-  shouldn\xE2\x80\x99t be doing that anyway.  In fact, you should never mock or stub methods\n\
-  on value objects.\n\n\
-  ## Integration ##\n\n\
-  Lookout can be used from [Rake][].  Simply include the following code in your\n\
-  `Rakefile`:\n\n    require 'lookout/rake/tasks'\n\n    Lookout::Rake::Tasks::Test.new\n\n\
-  If the `:default` task hasn\xE2\x80\x99t been defined it will be set to depend on the\n\
-  `:test` task.\n\n\
-  As an added bonus you can use Lookouts own [gem][RubyGems] 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 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 the\n\
-  implementation file is active, or run the test at or just before the cursor, if\n\
-  the test file is active.  This is useful if you\xE2\x80\x99re currently receiving a lot of\n\
-  errors and/or failures and want to focus on those associated with a specific\n\
-  class or on a specific test.\n\n\
-  [Rake]: http://rake.rubyforge.org\n\
-  [RubyGems]: http://rubygems.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, as\n\
-  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\xE2\x80\x99re worried that\n\
-  your tests aren\xE2\x80\x99t being run, but if you worry about that, then providing such\n\
-  output doesn\xE2\x80\x99t really help.  Testing your tests requires something beyond\n\
-  reporting some arbitrary count that you would have to verify by hand anyway.\n\n\
-  When errors or failures do occur, however, the relevant information is output\n\
-  in a format that can easily be parsed by an `'errorformat'` for [Vim][] or with\n\
-  [Compilation Mode][] for [Emacs][].  Diffs are generated for Strings, Arrays,\n\
-  Hashes, and I/O.\n\n\
-  [Vim]: http://www.vim.org\n\
-  [Compilation Mode]: http://www.emacswiki.org/emacs/CompilationMode\n\
-  [Emacs]: http://www.gnu.org/software/emacs/\n\n\
-  ## External Design ##\n\n\
-  Let\xE2\x80\x99s 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\xE2\x80\x99re testing\n\
-  behavior with a mock, then only one method-invocation expectation can be set.\n\
-  If you\xE2\x80\x99re testing state, then only one result can be verified.  It may seem\n\
-  like this would cause unnecessary duplication between tests.  While this is\n\
-  certainly a possibility, when you actually begin to try to avoid such\n\
-  duplication you find that you often do so by improving your interfaces.  This\n\
-  kind of restriction tends to encourage the use of value objects, which are easy\n\
-  to test, and more focused objects, which require simpler tests, as they have\n\
-  less behavior to test, per method.  By keeping your interfaces focused you\xE2\x80\x99re\n\
-  also keeping your tests focused.\n\n\
-  Keeping your tests focused improves, in itself, test isolation, but let\xE2\x80\x99s look\n\
-  at something that hinders it: setup and teardown methods.  Most unit testing\n\
-  frameworks encourage test fragmentation by providing setup and teardown\n\
-  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\xE2\x80\x99s\n\
-  being done in a test.  This may work fine for few methods with simple set-ups,\n\
-  but makes things complicated when the number of tests increases and the set-up\n\
-  is complex.  Often, each test further adjusts the previously set-up object\n\
-  before performing any verifications, further complicating the process of\n\
-  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 test\n\
-  in the test itself, thus improving test isolation.  (You also won\xE2\x80\x99t [slow down\n\
-  your tests][Broken Test::Unit] by keeping unnecessary state.)\n\n\
-  Most unit test frameworks also allow you to create arbitrary test helper\n\
-  methods.  Lookout doesn\xE2\x80\x99t.  The same rationale as that that has been\n\
-  crystallized in the preceding paragraphs applies.  If you need helpers you\xE2\x80\x99re\n\
-  interface isn\xE2\x80\x99t good enough.  It really is as simple as that.\n\n\
-  To clarify: there\xE2\x80\x99s nothing inherently wrong with test helper methods, but they\n\
-  should be general enough that they reside in their own library.  The support\n\
-  for mocks in Lookout is provided through a set of test helper methods that make\n\
-  it easier to create mocks than it would have been without them.\n\
-  [Lookout-rack][] is another example of a library providing test helper methods\n\
-  (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 further\n\
-  is documentation.  These frameworks provide ways of describing the whats and\n\
-  hows of what\xE2\x80\x99s being tested, the rationale being that this will provide\n\
-  documentation of both the test and the code being tested.  Describing how a\n\
-  stack data structure is meant to work is a common example.  A stack is,\n\
-  however, a rather simple data structure, so such a description provides little,\n\
-  if any, additional information that can\xE2\x80\x99t be extracted from the implementation\n\
-  and its tests themselves.  The implementation and its tests is, in fact, its\n\
-  own best documentation.  Taking the points made in the previous paragraphs into\n\
-  account, we should already have simple, self-describing, interfaces that have\n\
-  easily understood tests associated with them.  Rationales for the use of a\n\
-  given data structure or system-design design documentation is better suited in\n\
-  separate documentation focused at describing exactly those issues.\n\n\
-  [Resource Acquisition Is Initialization]: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization\n\
-  [Broken Test::Unit]: http://37signals.com/svn/posts/2742-the-road-to-faster-tests\n\
-  [Lookout-rack]: http://github.com/now/lookout-rack\n\
-  [Rack]: 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\xE2\x80\x99s 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 the\n\
-  Mocha installation directory.  I reported it, provided a patch five days later,\n\
-  then waited.  Nothing happened.  254 days later, according to [Wolfram\n\
-  Alpha][254 days], half of my patch was, apparently \xE2\x80\x93 I say \xE2\x80\x9Capparently\xE2\x80\x9D, as I\n\
-  received no notification \xE2\x80\x93 applied.  By that time I had replaced the whole\n\
-  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\xE2\x80\x99t the case and that the real problem is instead related to sloppy\n\
-  practices.\n\n\
-  Please note that I don\xE2\x80\x99t 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 \xE2\x80\x9Cconsidered harmful\xE2\x80\x9D.\n\n\
-  [254 days]: http://www.wolframalpha.com/input/?i=days+between+march+17%2C+2010+and+november+26%2C+2010\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 other\n\
-  part of the system as a whole and could be moved into its own library at a time\n\
-  where that would be of interest to anyone.  What\xE2\x80\x99s perhaps more interesting is\n\
-  that the diff subsystem is itself very modular.  The data passes through a set\n\
-  of filters that depends on what kind of diff has been requested, each filter\n\
-  yielding modified data as it receives it.  If you want to read some rather\n\
-  functional Ruby I can highly recommend looking at the code in the\n\
-  `lib/lookout/diff` directory.\n\n\
-  This lookout on the design of the library also makes it easy to extend Lookout.\n\
-  Lookout-rack was, for example, written in about four hours and about 5 of those\n\
-  240 minutes were spent on setting up the interface between 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\xE2\x80\x99ve always worried about speed.  The original Expectations library used\n\
-  `extend` a lot to add new behavior to objects.  Expectations, for example, used\n\
-  to hold the result of their execution (what we now term \xE2\x80\x9Cevaluation\xE2\x80\x9D) by being\n\
-  extended by a module representing success, failure, or error.  For the longest\n\
-  time I used this same method, worrying about the increased performance cost\n\
-  that creating new objects for results would incur.  I finally came to a point\n\
-  where I felt that the code was so simple and clean that rewriting this part of\n\
-  the code for a benchmark wouldn\xE2\x80\x99t take more than perhaps ten minutes.  Well,\n\
-  ten minutes later I had my results and they confirmed that creating new objects\n\
-  wasn\xE2\x80\x99t harming performance.  I was 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 \xE2\x80\x9Cbest practice\xE2\x80\x9D in the Ruby\n\
-  community is to put `BeginEndStorage` in a file called `begin_end_storage.rb`,\n\
-  I only name constants using a single noun.  This has had the added benefit that\n\
-  classes seem to have acquired less behavior, as using a single noun doesn\xE2\x80\x99t\n\
-  allow you to tack on additional behavior without questioning if it\xE2\x80\x99s really\n\
-  appropriate to do so, given the rather limited range of interpretation for that\n\
-  noun.  It also seems to encourage the creation of value objects, as something\n\
-  named `Range` feels a lot more like a value than `BeginEndStorage`.  (To reach\n\
-  object-oriented-programming 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 [let us\n\
-  know][Lookout issues] if you do.\n\n  * Nikolai Weibull\n\n\
-  [Lookout issues]: https://github.com/now/lookout/issues\n\n\n\
-  ## License ##\n\n\
-  You may use, copy, and redistribute this library under the same [terms][] as\n\
-  Ruby itself.\n\n\
-  [terms]: http://www.ruby-lang.org/en/LICENSE.txt\n"
+  prerelease: false
+  version_requirements: *14599272
+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      and 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"
 email: now@bitwi.se
 executables: []
-
 extensions: []
-
 extra_rdoc_files: []
-
-files: 
-- lib/lookout/diff.rb
-- lib/lookout/diff/algorithms.rb
-- lib/lookout/diff/algorithms/difflib.rb
-- lib/lookout/diff/algorithms/difflib/position.rb
+files:
+- lib/lookout/aphonic.rb
 - lib/lookout/diff/algorithms/difflib/position/to.rb
-- lib/lookout/diff/formats.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.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/mock/method.rb
-- lib/lookout/mock/method/arguments.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/calls.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/test/loader.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/gem.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/results/failures.rb
-- lib/lookout/results/failures/behavior.rb
-- lib/lookout/results/failures/state.rb
-- lib/lookout/results/error/exception.rb
+- lib/lookout/recorders.rb
+- lib/lookout/result.rb
 - lib/lookout/results/error/exception/backtrace.rb
-- lib/lookout/results/unsuccessful.rb
+- lib/lookout/results/error/exception.rb
 - lib/lookout/results/error.rb
-- lib/lookout/results/fulfilled.rb
-- lib/lookout/results/instance.rb
 - lib/lookout/results/failure.rb
-- lib/lookout/runners.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/ui.rb
-- lib/lookout/ui/silent.rb
+- lib/lookout/stub.rb
 - lib/lookout/ui/console.rb
-- lib/lookout/xml.rb
-- lib/lookout/aphonic.rb
-- lib/lookout/recorder.rb
-- lib/lookout/recorders.rb
-- lib/lookout/expectation.rb
+- lib/lookout/ui/silent.rb
+- lib/lookout/ui.rb
 - lib/lookout/version.rb
-- lib/lookout/expectations.rb
-- lib/lookout/equalities/object.rb
-- lib/lookout/equalities/include.rb
-- lib/lookout/equalities/boolean.rb
-- lib/lookout/equalities/string.rb
-- lib/lookout/equalities/array.rb
-- lib/lookout/equalities/hash.rb
-- lib/lookout/equalities/standarderror.rb
-- lib/lookout/equalities/output.rb
-- lib/lookout/equalities/warning.rb
-- lib/lookout/equality.rb
 - lib/lookout/warning.rb
-- lib/lookout/mock.rb
-- lib/lookout/stub.rb
-- lib/lookout/results.rb
-- lib/lookout/result.rb
-- lib/lookout/equalities.rb
+- lib/lookout/xml.rb
 - lib/lookout.rb
-- test/unit/lookout/diff.rb
-- test/unit/lookout/diff/algorithms/difflib.rb
-- test/unit/lookout/diff/algorithms/difflib/position.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.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/state.rb
 - test/unit/lookout/expectations/behavior.rb
-- test/unit/lookout/mock/method.rb
-- test/unit/lookout/mock/method/arguments.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/unsuccessful.rb
-- test/unit/lookout/results/error.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/formatters/exception.rb
-- test/unit/lookout/ui/formatters/exception/backtrace.rb
+- test/unit/lookout/ui/console.rb
 - test/unit/lookout/xml.rb
-- test/unit/lookout/results.rb
-- test/unit/lookout/expectations.rb
-- test/unit/examples.rb
 - test/unit/lookout.rb
 - README
 - Rakefile
-has_rdoc: true
 homepage: http://github.com/now/lookout
 licenses: []
-
+metadata: {}
 post_install_message: 
 rdoc_options: []
-
-require_paths: 
+require_paths:
 - lib
-required_ruby_version: !ruby/object:Gem::Requirement 
+required_ruby_version: !ruby/object:Gem::Requirement
   none: false
-  requirements: 
-  - - ">="
-    - !ruby/object:Gem::Version 
-      hash: 3
-      segments: 
-      - 0
-      version: "0"
-required_rubygems_version: !ruby/object:Gem::Requirement 
+  requirements:
+  - - ! '>='
+    - !ruby/object:Gem::Version
+      version: '0'
+required_rubygems_version: !ruby/object:Gem::Requirement
   none: false
-  requirements: 
-  - - ">="
-    - !ruby/object:Gem::Version 
-      hash: 3
-      segments: 
-      - 0
-      version: "0"
+  requirements:
+  - - ! '>='
+    - !ruby/object:Gem::Version
+      version: '0'
 requirements: []
-
 rubyforge_project: 
-rubygems_version: 1.3.7
+rubygems_version: 1.8.10
 signing_key: 
-specification_version: 3
+specification_version: 4
 summary: Lookout is a lightweight unit testing framework.
 test_files: []
-