lookout 3.0.0 → 3.0.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: cc52934f56620430dc02396b94d8d69b851e598e
-  data.tar.gz: 5478d2367e690c3b8f0bf6f65972929a6ee63aa1
+  metadata.gz: 2bb581b92138321c4bd16f652fc409144819e8e8
+  data.tar.gz: 98671835586ef400221e6dd5027930bdfab4ab11
 SHA512:
-  metadata.gz: 44aab8e8553f1c1c682082dc2e7476282f4928c488b25b8c6279e8be12fad7273176ff3e31560addaf64d1a05b616c3129a6b00ea9f6a8ad6946238e0a03dbf6
-  data.tar.gz: e1b577bbb0d2d61e1498141ec4e05552e9fb15233bbdcd54a66f0f167feaf92b379bdd81683b9b1b748b9065b1a689cfb7c21b20d9fc5b029c6d1d2e95368a66
+  metadata.gz: f2cacea2da550247f2dcfb709c0b830054c54fca2f229b8095a49ede2454337e4fc39f24e8e96140158d66afcb5bd931f53b0601dc9d32bdb5ff762e52a124fb
+  data.tar.gz: 3a2aa060d044b736609987c5604e5868d7afbdc6ea023023bbfa493e35571593a2f3cc01d8d1cd5749be2248698e0982cf4265c846287c3db69d41c634208f3d

data/README

@@ -666,8 +666,8 @@
   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 Lookout-rack home page at
+  http://disu.se/software/lookout-rack/
 ⁴ Visit the Rack Rubyforge project page at
   http://rack.rubyforge.org/
 
@@ -812,7 +812,7 @@
     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
+  https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now%40disu%2ese&item_name=Lookout
 
 § Reporting Bugs
 
@@ -830,9 +830,12 @@
 
 ¹ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues
 
-§ License
+§ Licensing
 
-    You may use, copy, and redistribute this library under the same terms¹
-    as Ruby itself.
+    Lookout is free software: you may redistribute it and/or modify it under
+    the terms of the {GNU Lesser General Public License, version 3}¹ or later²,
+    as published by the {Free Software Foundation}³.
 
-¹ Read the Ruby licensing terms at http://www.ruby-lang.org/en/LICENSE.txt
+¹ See http://disu.se/licenses/lgpl-3.0/
+² See http://gnu.org/licenses/
+³ See http://fsf.org/

data/Rakefile

@@ -4,11 +4,7 @@ require 'inventory-rake-1.0'
 
 load File.expand_path('../lib/lookout-3.0/version.rb', __FILE__)
 
-Inventory::Rake::Tasks.define Lookout::Version, :gem => proc{ |_, s|
-  s.author = 'Nikolai Weibull'
-  s.email = 'now@bitwi.se'
-  s.homepage = 'https://github.com/now/lookout'
-}
+Inventory::Rake::Tasks.define Lookout::Version
 
 Inventory::Rake::Tasks.unless_installing_dependencies do
   require 'lookout-rake-3.0'

data/lib/lookout-3.0/version.rb

@@ -3,12 +3,24 @@
 require 'inventory-1.0'
 
 module Lookout
-  Version = Inventory.new(3, 0, 0){
+  Version = Inventory.new(3, 0, 1){
+    authors{
+      author 'Nikolai Weibull', 'now@disu.se'
+    }
+
+    homepage 'http://disu.se/software/lookout'
+
+    licenses{
+      license 'LGPLv3+',
+              'GNU Lesser General Public License, version 3 or later',
+              'http://www.gnu.org/licenses/'
+    }
+
     def dependencies
       super + Inventory::Dependencies.new{
-        development 'inventory-rake', 1, 4, 0
-        development 'inventory-rake-tasks-yard', 1, 3, 0
-        development 'lookout-rake', 3, 0, 0
+        development 'inventory-rake', 1, 6, 0
+        development 'inventory-rake-tasks-yard', 1, 4, 0
+        development 'lookout-rake', 3, 1, 0
         development 'yard', 0, 8, 0
         development 'yard-heuristics', 1, 1, 0
         development 'yard-value', 1, 2, 0

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: lookout
 version: !ruby/object:Gem::Version
-  version: 3.0.0
+  version: 3.0.1
 platform: ruby
 authors:
 - Nikolai Weibull
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2013-04-30 00:00:00.000000000 Z
+date: 2013-09-04 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: inventory
@@ -16,56 +16,56 @@ dependencies:
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '1.4'
+        version: '1.5'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '1.4'
+        version: '1.5'
 - !ruby/object:Gem::Dependency
   name: inventory-rake
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '1.4'
+        version: '1.6'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '1.4'
+        version: '1.6'
 - !ruby/object:Gem::Dependency
   name: inventory-rake-tasks-yard
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '1.3'
+        version: '1.4'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '1.3'
+        version: '1.4'
 - !ruby/object:Gem::Dependency
   name: lookout-rake
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '3.0'
+        version: '3.1'
   type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - ~>
       - !ruby/object:Gem::Version
-        version: '3.0'
+        version: '3.1'
 - !ruby/object:Gem::Dependency
   name: yard
   requirement: !ruby/object:Gem::Requirement
@@ -125,7 +125,7 @@ dependencies:
 description: |2
                                   Lookout
 
-    Lookout is a unit testing framework for Ruby¹ that puts your results in
+    Lookout is a unit testing framework for Ruby┬╣ that puts your results in
     focus. Tests (expectations) are written as follows
 
       expect 2 do
@@ -144,55 +144,55 @@ description: |2
         [1, 2, 3].map{ |i| i * 2 }
       end
 
-    Lookout is designed to encourage – force, even – unit testing best practices
+    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
+  ΓÇó   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
+  ΓÇó   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
+  ΓÇó   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
+  ΓÇó   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
+  ΓÇó   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}⁵.
+    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:
+  ┬╣ 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/
+  ⁵ Nikolai Weibull’s home page: http://disu.se/
 
-  § Installation
+  § Installation
 
       Install Lookout with
 
         % gem install lookout
 
 
-  § Usage
+  § 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
+      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
+    § Expectations on State: Literals
 
         An expectation can be made on the result of a computation:
 
@@ -201,7 +201,7 @@ description: |2
           end
 
         Most objects, in fact, have their state expectations checked by invoking
-        ‹#==› on the expected value with the result as its argument.
+        ‹#==› on the expected value with the result as its argument.
 
         Checking that a result is within a given range is also simple:
 
@@ -209,29 +209,29 @@ description: |2
             0.4 - 0.3
           end
 
-        Here, the more general ‹#===› is being used on the ‹Range›.
+        Here, the more general ‹#===› is being used on the ‹Range›.
 
-    § Regexps
+    § Regexps
 
-        ‹Strings› of course match against ‹Strings›:
+        ‹Strings› of course match against ‹Strings›:
 
           expect 'ab' do
             'abc'[0..1]
           end
 
-        but we can also match a ‹String› against a ‹Regexp›:
+        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 /…/›.)
+        (Note the use of ‹%r{…}› to avoid warnings that will be generated when
+        Ruby parses ‹expect /…/›.)
 
-    § Modules
+    § Modules
 
         Checking that the result includes a certain module is done by expecting the
-        ‹Module›.
+        ‹Module›.
 
           expect Enumerable do
             []
@@ -244,13 +244,13 @@ description: |2
             'a string'
           end
 
-        This doesn’t hinder us from expecting the actual ‹Module› itself:
+        This doesn’t hinder us from expecting the actual ‹Module› itself:
 
           expect Enumerable do
             Enumerable
           end
 
-        or the ‹Class›:
+        or the ‹Class›:
 
           expect String do
             String
@@ -259,12 +259,12 @@ description: |2
         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›.
+        trying ‹#==› and, if it returns ‹false›, then trying ‹#===› on the
+        expected ‹Module›.  This is also true of ‹Ranges› and ‹Regexps›.
 
-    § Booleans
+    § Booleans
 
-        Truthfulness is expected with ‹true› and ‹false›:
+        Truthfulness is expected with ‹true› and ‹false›:
 
           expect true do
             1
@@ -274,7 +274,7 @@ description: |2
             nil
           end
 
-        Results equaling ‹true› or ‹false› are slightly different:
+        Results equaling ‹true› or ‹false› are slightly different:
 
           expect TrueClass do
             true
@@ -286,9 +286,9 @@ description: |2
 
         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›.
+        false, not the exact literals ‹true› or ‹false›.
 
-    § IO
+    § IO
 
         Expecting output on an IO object is also common:
 
@@ -299,9 +299,9 @@ description: |2
         This can be used to capture the output of a formatter that takes an
         output object as a parameter.
 
-    § Warnings
+    § Warnings
 
-        Expecting warnings from code isn’t very common, but should be done:
+        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!'
@@ -311,9 +311,9 @@ description: |2
             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›
+        ‹$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
@@ -321,10 +321,10 @@ description: |2
             end
           end
 
-    § Errors
+    § Errors
 
-        You should always be expecting errors from – and in, but that’s a
-        different story – your code:
+        You should always be expecting errors from ΓÇô and in, but thatΓÇÖs a
+        different story ΓÇô your code:
 
           expect ArgumentError do
             Integer('1 + 1')
@@ -337,25 +337,25 @@ description: |2
             raise StandardError.new('message')
           end
 
-        As with ‹Strings›, ‹Regexps› can be used to check the error description:
+        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
+    § 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
+        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 ‹?›:
+        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_›:
+        To expect it’s negation, expect the same symbol beginning with ‹not_›:
 
           expect :not_nil? do
             [1, 2, 3]
@@ -374,19 +374,19 @@ description: |2
           end
 
         but provides much clearer failure messages.  It also makes the
-        expectation’s intent a lot clearer.
+        expectationΓÇÖs intent a lot clearer.
 
-    § Queries By Proxy
+    § Queries By Proxy
 
-        There’s also a way to make the expectations of query methods explicit by
+        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
+        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:
+        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? }
@@ -399,34 +399,34 @@ description: |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
+        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
+        The keyword for this kind of expectations is ‹result›.  This may be
         followed by any of the methods
 
-      •   ‹#not›
-      •   ‹#to›
-      •   ‹#be›
-      •   ‹#have›
+      •   ‹#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.
+        ‹#to›, ‹#be›, and ‹#have› do nothing except improve readability.  The
+        ‹#not› method inverts the expectation.
 
-    § Literal Literals
+    § 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 ‹?›
+      •   ‹Module›
+      •   ‹Range›
+      •   ‹Regexp›
+      •   ‹Exception›
+      •   ‹Symbol›, given that it ends with ‹?›
 
-        you can do so by wrapping it in ‹literal(…)›:
+        you can do so by wrapping it in ‹literal(…)›:
 
           expect literal(:empty?) do
             :empty?
@@ -435,7 +435,7 @@ description: |2
         You almost never need to do this, as, for all but symbols, instances will
         match accordingly as well.
 
-    § Expectations on Behavior
+    § Expectations on Behavior
 
         We expect our objects to be on their best behavior.  Lookout allows you
         to make sure that they are.
@@ -447,15 +447,15 @@ description: |2
             o.to_str
           end
 
-        Here, ‹#mock› creates a mock object, an object that doesn’t respond to
+        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
+        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
+        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.
 
@@ -463,30 +463,30 @@ description: |2
             o.to_str if o.convertable?
           end
 
-        You don’t have to use a mock object to verify that a method is called:
+        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
+        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
+        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
+        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
+        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
+        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:
 
@@ -501,24 +501,24 @@ description: |2
           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›.
+        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›:
+        ‹without_arguments›:
 
           expect mock.to.receive.a(without_arguments) do |m|
             m.a
           end
 
-        You can of course use both ‹Object› and actual arguments:
+        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›:
+        ‹#a› on ‹m› will give the result ‹1›:
 
           expect mock.to.receive.a{ 1 } do |m|
             raise 'not 1' unless m.a == 1
@@ -526,7 +526,7 @@ description: |2
 
         If no body has been given, the result will be a stub object.
 
-        To take a block, grab a block parameter and ‹#call› it:
+        To take a block, grab a block parameter and ‹#call› it:
 
           expect mock.to.receive.a{ |&b| b.call(1) } do |m|
             j = 0
@@ -534,34 +534,34 @@ description: |2
             raise 'not 1' unless j == 1
           end
 
-        To simulate an ‹#each›-like method, ‹#call› the block several times.
+        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
+        ΓÇ£at least onceΓÇ¥ isnΓÇÖt good enough.  The following expectations are
         possible
 
-      •   ‹#at_most_once›
-      •   ‹#once›
-      •   ‹#at_least_once›
-      •   ‹#twice›
+      •   ‹#at_most_once›
+      •   ‹#once›
+      •   ‹#at_least_once›
+      •   ‹#twice›
 
-        And, for a given ‹N›,
+        And, for a given ‹N›,
 
-      •   ‹#at_most(N)›
-      •   ‹#exactly(N)›
-      •   ‹#at_least(N)›
+      •   ‹#at_most(N)›
+      •   ‹#exactly(N)›
+      •   ‹#at_least(N)›
 
-    § Utilities: Stubs
+    § 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
+        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|
@@ -576,7 +576,7 @@ description: |2
                  }.new, :slips => [1, 2, 3]){ |account| account.total }
           end
 
-        To make it easy to create objects with a set of stubbed methods there’s
+        To make it easy to create objects with a set of stubbed methods thereΓÇÖs
         also a convenience method:
 
           expect 3 do
@@ -611,10 +611,10 @@ description: |2
 
         The stub is active during the execution of the block.
 
-    § Overriding Constants
+    § 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:
+        execution of some code.  Use ‹#with_const› to do just that:
 
           expect 'hello' do
             with_const 'A::B::C', 'hello' do
@@ -622,19 +622,19 @@ description: |2
             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.
+        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
+    § 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
+        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:
@@ -645,10 +645,10 @@ description: |2
             end
           end
 
-        Any overridden values are restored and any keys that weren’t previously a
+        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
+    § Overriding Globals
 
         You may also want to override the value of a global temporarily:
 
@@ -669,9 +669,9 @@ description: |2
             end
           end
 
-  § Integration
+  § Integration
 
-      Lookout can be used from Rake¹.  Simply install Lookout-Rake²:
+      Lookout can be used from Rake┬╣.  Simply install Lookout-Rake┬▓:
 
         % gem install lookout-rake
 
@@ -684,17 +684,17 @@ description: |2
       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/
+  ┬╣ Read more about Rake at http://rake.rubyforge.org/
+  ┬▓ Get information on Lookout-Rake at http://disu.se/software/lookout-rake/
 
-  § API
+  § API
 
-      Lookout comes with an API¹ that let’s you create things such as new
+      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/
+  ┬╣ See http://disu.se/software/lookout/api/
 
-  § Interface Design
+  § 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,
@@ -703,44 +703,44 @@ description: |2
       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
+      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,
+      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/
+  ┬╣ 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
+  § External Design
 
-      Let’s now look at some of the points made in the introduction in greater
+      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
+      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
+      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
+      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
+      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
+      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
@@ -753,32 +753,32 @@ description: |2
       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.
+      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.)
+      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
+      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.
+      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
+      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
+      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⁴.
+      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
+      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
+      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,
@@ -787,144 +787,144 @@ description: |2
       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
+  ┬╣ 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
+  ┬▓ 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
+  ┬│ Visit the Lookout-rack home page at
+    http://disu.se/software/lookout-rack/
+  ⁴ Visit the Rack Rubyforge project page at
     http://rack.rubyforge.org/
 
-  § Internal Design
+  § 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
+    ΓÇó   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
+  § 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
+      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
+      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
+      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
+      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
+      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”.
+      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/
+  ┬╣ 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
+  § 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
+      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.
+      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
+  § 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”)
+      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
+      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
+      they confirmed that creating new objects wasnΓÇÖt harming performance.  I was
       very pleased.
 
-  § Naming
+  § 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
+      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
+      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
+      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
+  § News
 
-    § 3.0.0
+    § 3.0.0
 
-        The ‹xml› expectation has been dropped.  It wasn’t documented, didn’t
+        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 ‹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
+        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 ‹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.
+        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›).
+        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.
+        The ‹literal› expectation was added.
 
-        Equality (‹#==›) is now checked before “caseity” (‹#===›) for modules,
+        Equality (‹#==›) is now checked before “caseity” (‹#===›) for modules,
         ranges, and regular expressions to match the documentation.
 
-  § Financing
+  § 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
@@ -934,34 +934,38 @@ description: |2
       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!
+      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
+  ┬╣ Send a donation:
+    https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=now%40disu%2ese&item_name=Lookout
 
-  § Reporting Bugs
+  § Reporting Bugs
 
-      Please report any bugs that you encounter to the {issue tracker}¹.
+      Please report any bugs that you encounter to the {issue tracker}┬╣.
 
-    ¹ See https://github.com/now/lookout/issues
+    ┬╣ See https://github.com/now/lookout/issues
 
-  § Contributors
+  § 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.
+      {let us know}┬╣ if you do.
 
-    •   Nikolai Weibull
+    ΓÇó   Nikolai Weibull
 
-  ¹ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues
+  ┬╣ Add an issue to the Lookout issue tracker at https://github.com/now/lookout/issues
 
-  § License
+  § Licensing
 
-      You may use, copy, and redistribute this library under the same terms¹
-      as Ruby itself.
+      Lookout is free software: you may redistribute it and/or modify it under
+      the terms of the {GNU Lesser General Public License, version 3}┬╣ or later┬▓,
+      as published by the {Free Software Foundation}┬│.
 
-  ¹ Read the Ruby licensing terms at http://www.ruby-lang.org/en/LICENSE.txt
-email: now@bitwi.se
+  ┬╣ See http://disu.se/licenses/lgpl-3.0/
+  ┬▓ See http://gnu.org/licenses/
+  ┬│ See http://fsf.org/
+email:
+- now@disu.se
 executables: []
 extensions: []
 extra_rdoc_files: []
@@ -1177,8 +1181,9 @@ files:
 - test/unit/examples.rb
 - README
 - Rakefile
-homepage: https://github.com/now/lookout
-licenses: []
+homepage: http://disu.se/software/lookout
+licenses:
+- LGPLv3+
 metadata: {}
 post_install_message: 
 rdoc_options: []
@@ -1196,7 +1201,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
       version: '0'
 requirements: []
 rubyforge_project: 
-rubygems_version: 2.0.0
+rubygems_version: 2.0.2
 signing_key: 
 specification_version: 4
 summary: focus.