muack 0.7.3 → 1.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 0f70136437354cf553340e7a4502e6fc4056802e
-  data.tar.gz: 4f73fe1b681f0e6b4b837f89e72865a008f721af
+  metadata.gz: fbb0455780531e5a3b3dc2519ba3fa1179f65866
+  data.tar.gz: 91445ca9d049d32bfb110566e4403883158071e5
 SHA512:
-  metadata.gz: 832585b3ec72cf71fdd5fd1a607034ddd999e509d03e8239037fc2bb7a3a9d1637996a09ec2e1d2d45ace2539d3b8d4ee5c6877df02ed3a0113e3e2f125d8869
-  data.tar.gz: c9c64a40ec5c10d2cbdf30d17c3952b857915160f7599f8a2258db88ad53d668d75c5f493399d0f315c811d9164ab41267498b329fa2bf8202f2f0dcfe93893f
+  metadata.gz: 9e02fc19cb16d91758b6122e2e704ea81ff298e7766806e1bf08a29be6daebe113635ca943ef0308ccea9cb345d60e46f1699112869b9f3c5a4883cc9c5d5cc3
+  data.tar.gz: 5a4e374c7f7cd81f379817143b7b82939f76a918b6aac6dfc44fd452823fc6a570111a56c033f416630b93106a9b02d81808ba91e342d2a6e27f1107b1d3c66e

data/.gitignore

@@ -1,2 +1 @@
 /pkg/
-*.rbc

data/.travis.yml

@@ -1,11 +1,9 @@
 before_install: 'git submodule update --init'
 script: 'ruby -r bundler/setup -S rake test'
 
-env:
-  - 'RBXOPT=-X19'
-
 rvm:
   - 1.9.3
   - 2.0.0
-  - rbx-head
-  - jruby-head
+  - 2.1.0
+  - rbx
+  - jruby

data/CHANGES.md

@@ -1,5 +1,73 @@
 # CHANGES
 
+## Muack 1.0.0 -- ?
+
+Improvements:
+
+* The internal conflicting method names are now a bit more informative
+  and unique thus less likely to have conflicts.
+
+* Fixed a bug where mock and stub with the same method were defined.
+  Previously, it would raise an undefined method error upon verifying
+  while we're removing injected method. Now it could properly undefine
+  injected methods.
+
+* Fixed issues mocking private methods. Now it would not only work without
+  a problem, but also preserve the privilege if the original method is a
+  private method. Note that for now, protected methods are treated as
+  public methods though.
+
+* Fixed a bug where user customized Satisfy could crash if it's located
+  on a top-level. i.e. class names without ::.
+
+Incompatible changes:
+
+* Removed proxy method. From now on, if you do not pass a block to a
+  mock, then it would assume it's a proxy. You can think of instead of
+  make an empty block as a default, the original method is the default.
+  That means, previously, mock without a block would always return nil,
+  but now it instead means a proxy.
+
+* Introduced peek_args method. Sometimes I really need to peek the
+  arguments of a method, or trying to provide a different argument
+  based on the original argument. So peek_args is the way to do it.
+
+* Introduced peek_return method. By duality, we also introduce something
+  we can peek the return value. Using this along with a custom block
+  doesn't really make sense, but this is actually the previous proxy
+  block. Previously, if a mock is a proxy, then the block doesn't really
+  mean the implementation, but a modification to the original return.
+  That is, the current peek_return. Originally the block is quite
+  inconsistent as the semantics of the block would change depending on
+  it is a proxy or not.
+
+So to proxy the to_s method and then reverse the result, you write:
+
+``` ruby
+str = 'str'
+Muack::API.mock(str).to_s.peek_return{ |s| s.reverse }
+p str.to_s # => 'rts'
+```
+
+* Removed plain value argument in `returns`. From now on, we should
+  always use the block form. Instead, the argument was changed to be
+  an optional option for specifying if the underlying block should be
+  instance executed or not. By default, the block is lexical scoped.
+  If passing `:instance_exec => true` to `returns`, `peek_args`, and
+  `peek_return`, then the block is instead instance scoped, passing
+  to the instance's `instance_exec`. This way, we would be able to
+  touch the inside of mocked object.
+
+Without passing `:instance_exec => true`, `to_i` would be called on
+the top-level object instead. By passing this argument, `to_i` would be
+called in the string.
+
+``` ruby
+str = '123'
+Muack::API.mock(str).int.returns(:instance_exec => true){to_i}
+p str.int # => 123
+```
+
 ## Muack 0.7.3 -- 2013-10-01
 
 * Added `Muack::API.including(element)` for detecting if the underlying

data/Gemfile

@@ -5,3 +5,7 @@ gemspec
 
 gem 'rake'
 gem 'bacon'
+
+platform :rbx do
+  gem 'rubysl-singleton' # used in rake
+end

data/README.md

@@ -10,10 +10,10 @@ by Lin Jen-Shin ([godfat](http://godfat.org))
 
 ## DESCRIPTION:
 
-Muack -- Yet another mocking library.
+Muack -- A fast, small, yet powerful mocking library.
 
-Basically it's an [RR][] clone, but much faster under heavy use.
-It's 32x times faster (750s vs 23s) for running [Rib][] tests.
+Inspired by [RR][], and it's 32x times faster (750s vs 23s) than RR
+for running [Rib][] tests.
 
 [RR]: https://github.com/rr/rr
 [Rib]: https://github.com/godfat/rib
@@ -21,11 +21,11 @@ It's 32x times faster (750s vs 23s) for running [Rib][] tests.
 ## WHY?
 
 Because RR has/had some bugs and it is too complex for me to fix it.
-Muack is much simpler and thus much faster and less likely to have bugs.
+Muack is much simpler and thus much faster and much more consistent.
 
 ## REQUIREMENTS:
 
-* Tested with MRI (official CRuby) 1.9.3, 2.0.0, Rubinius and JRuby.
+* Tested with MRI (official CRuby) 2.0.0, 2.1.0, Rubinius and JRuby.
 
 ## INSTALLATION:
 
@@ -33,7 +33,7 @@ Muack is much simpler and thus much faster and less likely to have bugs.
 
 ## SYNOPSIS:
 
-Basically it's an [RR][] clone. Let's see a [Bacon][] example.
+Here's a quick example using [Bacon][].
 
 ``` ruby
 require 'bacon'
@@ -55,497 +55,944 @@ end
 
 [Bacon]: https://github.com/chneukirchen/bacon
 
-### Coming from RR?
+### Overview
 
-Basically since it's an RR clone, the APIs are much the same.
-Let's see what's the different with code snippets. All codes
-were extracted from
-[RR's API document](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md).
+There are 3 parts in Muack, which are:
 
-#### [mock](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#mock)
+* Mocks
+* Mocks Modifiers
+* Arguments Verifiers (Satisfy)
 
-`mock` is the same as RR.
+Mocks are objects with injected methods which we could observe, and mocks
+modifiers are telling how we want to observe the mocks, and finally argument
+verifiers could help us observe the arguments passed to the injected methods.
+
+Let's explain them one by one.
+
+### Mocks
+
+There are also 3 different kinds of mocks in Muack, which are:
+
+* Mocks
+* Stubs
+* Spies
+
+You could also think of _mocks_ are _stubs_ + _spies_. Here's the equation:
+
+    mock = stub + spy
+
+Stubs help us inject methods into the objects we want to observe. Spies
+help us observe the behaviours of the objects. As for mocks, they inject
+methods and observe the behaviours in realtime. They complain immediately
+if the behaviours were unexpected. In contrast, if we're not asking spies,
+stubs won't complain themselves.
+
+Here's an example using a mock:
 
 ``` ruby
-view = controller.template
-mock(view).render(:partial => "user_info") {"Information"}
+obj = Object.new
+mock(obj).name{ 'obj' }
+p obj.name     # 'obj'
+p Muack.verify # true
 ```
 
-There's no `twice` modifier in Muack, use `times(2)` instead.
+Which is roughly semantically equivalent to using a stub with a spy:
 
 ``` ruby
-mock(view).render.with_any_args.times(2) do |*args|
-  if args.first == {:partial => "user_info"}
-    "User Info"
-  else
-    "Stuff in the view #{args.inspect}"
-  end
-end
+obj = Object.new
+stub(obj).name{ 'obj' }
+p obj.name     # 'obj'
+spy(obj).name
+p Muack.verify # true
 ```
 
-#### [stub](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#stub)
+You might wonder, then why mocks or why stubs with spies? The advantage of
+using mocks is that, you only need to specify once. I guess this is quite
+obvious. However, sometimes we don't care if the injected methods are called
+or not, but sometimes we do care. With stubs and spies, we could always put
+stubs in the before/setup block, and only when we really care if they are
+called or not, we put spies to examine.
 
-`stub` is the same as RR.
+On the other hand, stubs aren't limited to testing. If we want to monkey
+patching something, stubs could be useful as we don't care how many times
+the injected methods are called. Jump to _Muack as a mocky patching library_
+section for more detail.
+
+Note that you could also mix mocks and stubs for a given object.
+Here's an example:
 
 ``` ruby
-jane = User.new
-bob = User.new
-stub(User).find('42') {jane}
-stub(User).find('99') {bob}
-stub(User).find do |id|
-  raise "Unexpected id #{id.inspect} passed to me"
-end
+obj = Object.new
+stub(obj).name{ 'obj' }
+mock(obj).id  { 12345 }
+p obj.name     # 'obj'
+p obj.id       # 12345
+p Muack.verify # true
 ```
 
-#### [times(0)](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#dont_allow-aliased-to-do_not_allow-dont_call-and-do_not_call)
+However you should not mix mocks and stubs with the same method, or you
+might encounter some unexpected result. Jump to _Caveat_ for more detail.
 
-There's no dont_allow method in Muack, use `times(0)` instead.
+#### Anonymous mode
+
+Sometimes we just want to stub something without a concrete object in mind.
+By calling `mock` or `stub` without any argument, we're creating an anonymous
+mock/stub. This is because the default argument for `mock` and `stub` is just
+`Object.new`.
+
+But how do we access the anonymously created object? We'll use the `object`
+method on the modifier to access it. Here's an example:
 
 ``` ruby
-User.find('42').times(0)
-User.find('42') # raises a Muack::Unexpected
+obj = mock.name{ 'obj' }.object
+p obj.name     # 'obj'
+p Muack.verify # true
 ```
 
-#### [proxy](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#mockproxy)
-
-Instead of calling `proxy` immediately after calling `mock`, we put
-`proxy` the last because it's a method from `Muack::Modifier`.
+This is exactly equivalent to this:
 
 ``` ruby
-view = controller.template
-mock(view).render(:partial => "right_navigation").proxy
-mock(view).render(:partial => "user_info") do |html|
-  html.should include("John Doe")
-  "Different html"
-end.proxy
+mock(obj = Object.new).name{ 'obj' }
+p obj.name     # 'obj'
+p Muack.verify # true
 ```
 
-If you feel it is weird to put proxy the last, you can also use
-`returns` modifier to put the block last as this:
+Also, if we want to mock over multiple methods, we could also take the
+advantage of block form of `mock` and `stub` method.
 
 ``` ruby
-view = controller.template
-mock(view).render(:partial => "right_navigation").proxy
-mock(view).render(:partial => "user_info").proxy.returns do |html|
-  html.should include("John Doe")
-  "Different html"
-end
+obj = mock{ |m|
+  m.name{ 'obj' }
+  m.id  { 12345 }
+}.object
+p obj.name     # 'obj'
+p obj.id       # 12345
+p Muack.verify # true
 ```
 
-The same goes to `stub`.
+We can't omit the `object` method here because after defining the injected
+method, we'll get a modifier to describe the properties of the injected
+method. Jump to _Mocks Modifiers_ for details.
+
+#### Proxy mode
+
+There are chances that we don't really want to change the underlying
+implementation for a given method, but we still want to make sure the
+named method is called, and that's what we're testing for.
+
+In those cases, proxy mode would be quite helpful. To turn a mock or stub
+into proxy mode we simply do not provide any block to the injected method,
+but just name it. Here's an example:
 
 ``` ruby
-view = controller.template
-stub(view).render(:partial => "user_info") do |html|
-  html.should include("Joe Smith")
-  html
-end.proxy
+str = 'str'
+mock(str).reverse
+p str.reverse  # 'rts'
+p Muack.verify # true
 ```
 
-Or use `returns`:
+Note that if reverse was not called exactly once, the mock would complain.
+We could also use stub + spy to do the same thing as well:
 
 ``` ruby
-view = controller.template
-stub(view).render(:partial => "user_info").proxy.returns do |html|
-  html.should include("Joe Smith")
-  html
-end
+str = 'str'
+stub(str).reverse
+p str.reverse  # 'rts'
+spy(str).reverse
+p Muack.verify # true
 ```
 
-#### [any_instance_of](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#any_instance_of)
+You might also want to use `peek_args` and `peek_return` modifier along with
+proxies in order to slightly tweak the original implementation. Jump to
+_Muack as a mocky patching library_ section for more detail.
+
+#### any_instance_of mode
+
+We only talked about mocking a specific object, but never mentioned what if
+the objects we want to mock aren't at hand at the time we define mocks?
+In those cases, instead of trying to mock object creation and return the
+mock we defined, we might want to simply mock any instance of a particular
+class, since this would make the process much easier.
 
-Only this form of `any_instance_of` is supported. On the other hand,
-any of the above is supported as well, not only stub.
+Here we could use a special "mock" called `any_instance_of`, which takes a
+class and returns a `Muack::AnyInstanceOf` which represents the instance of
+the class we just passed. Having this special representation, we could treat
+it as if a real instance and define regular mocks/stubs on it. It would then
+applies to any instance of the class we gave.
+
+Example speaks:
 
 ``` ruby
-any_instance_of(User) do |u|
-  stub(u).valid? { false }
-  mock(u).errors { []    }
-  mock(u).save.proxy
-  stub(u).reload.proxy
-end
+array = any_instance_of(Array)
+stub(array).name{ 'array' }
+p [ ].name     # 'array'
+p [0].name     # 'array'
+p Muack.verify # true
 ```
 
-#### [Spies](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#spies)
+And as most of the time we don't care about the representation after mocks
+were defined, we could use the block form:
 
-We don't try to provide different methods for different testing framework,
-so that we don't have to create so many testing framework adapters, and
-try to be smart to find the correct adapter. There are simply too many
-testing frameworks out there. Ruby's built-in test/unit and minitest have
-a lot of different versions, so does rspec.
+``` ruby
+any_instance_of(Array) do |array|
+  stub(array).name{ 'array' }
+  stub(array).id  { 1234567 }
+end
+p [ ].name   # 'array'
+p [0].id     # 1234567
+p Muack.verify # true
+```
 
-Here we just try to do it the Muack's way:
+Note that if you need to access the real instance instead of the
+representation in the injected method, you might want to enable
+instance_exec mode. Please jump to _instance_exec mode_ section
+for more detail.
 
+Here's an quick example:
 
 ``` ruby
-subject = Object.new
-stub(subject).foo(1)
-subject.foo(1)
-
-spy(subject).foo(1)
-spy(subject).bar # This doesn't verify immediately.
-Muack.verify     # This fails, saying `bar` was never called.
+any_instance_of(Array) do |array|
+  p array.class # Muack::AnyInstanceOf
+  mock(array).name.returns(:instance_exec => true){ inspect }
+end
+p [0, 1].name   # '[0, 1]'
+p Muack.verify  # true
 ```
 
-#### [Block form](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#block-syntax)
-
-Block form is also supported. However we don't support `instance_eval` form.
-There's little point to use instance_eval since it's much more complicated
-and much slower.
+Lastly, you could also use `any_instance_of` along with proxy mode,
+or any other combination you could think of:
 
 ``` ruby
-script = MyScript.new
-mock(script) do |expect|
-  expect.system("cd #{RAILS_ENV}") {true}
-  expect.system("rake foo:bar") {true}
-  expect.system("rake baz") {true}
+any_instance_of(Array) do |array|
+  stub(array).name{ 'array' }
+  mock(array).max
 end
+p [ ].name     # 'array'
+p [0].max      # 0
+p Muack.verify # true
 ```
 
-#### [Nested mocks](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#double-graphs)
+Though you should still not mix mocks and stubs with the same method,
+and as you could tell from the above example, Muack would not complain
+for every array without calling `max` once. This is because any_instance_of
+would count on all instances, instead of individual instances. Here
+we're actually telling Muack that `max` should be called exactly once
+amongst all instances of array, and it is indeed called exactly once
+amongst two instances here.
+
+This might or might not be what we want. But think it twice, if we're
+mocking any instance of a very basic class in Ruby, testing against
+individual instances could be too strict since it's used everywhere!
+
+Please check _Caveat_ section for more details.
+
+### Mocks Modifiers
+
+A modifier is something specifying a property of an injected method.
+By making a mock/stub/spy, it would return a modifier descriptor which
+we could then specify properties about the injected method.
+
+Note that we could chain properties for a given modifier descriptor
+because all public methods for declaring a property would return the
+modifier descriptor itself. Let's see the specific usages for each
+properties with concrete examples.
+
+#### times
 
-The shortest API (which might be a bit tricky) is not supported,
-but we do support:
+By using mocks, we are saying that the injected method should be called
+exactly once. However the injected method might be called more than once,
+say, twice. We could specify this with `times` modifier:
 
 ``` ruby
-stub(object).foo { stub.bar{ :baz }.object }
-object.foo.bar  #=> :baz
+obj = Object.new
+mock(obj).name{ 'obj' }.times(2)
+p obj.name     # 'obj'
+p obj.name     # 'obj'
+p Muack.verify # true
 ```
 
-And of course the verbose way:
+This is actually also semantically equivalent to making the mock twice:
 
 ``` ruby
-bar = stub.bar{ :baz }.object
-stub(object).foo { bar }
-object.foo.bar  #=> :baz
+obj = Object.new
+mock(obj).name{ 'obj' }
+mock(obj).name{ 'obj' }
+p obj.name     # 'obj'
+p obj.name     # 'obj'
+p Muack.verify # true
 ```
 
-Or even more verbose, of course:
+Note that it does not make sense to specify `times` for stubs, because
+stubs don't care about times. Spies do, though. So this is also
+semantically equivalent to below:
 
 ``` ruby
-bar = Object.new
-stub(bar).bar{ :baz }
-stub(object).foo { bar }
-object.foo.bar  #=> :baz
+obj = Object.new
+stub(obj).name{ 'obj' }
+p obj.name     # 'obj'
+p obj.name     # 'obj'
+spy(obj).name.times(2)
+p Muack.verify # true
 ```
 
-#### [Modifier](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#modifying-doubles)
-
-After defining a mock method, you get a `Muack::Modifier` back.
+Or without using times for spy:
 
 ``` ruby
-stub(object).foo     #=> Muack::Modifier
+obj = Object.new
+stub(obj).name{ 'obj' }
+p obj.name     # 'obj'
+p obj.name     # 'obj'
+spy(obj).name
+spy(obj).name
+p Muack.verify # true
 ```
 
-However, you cannot flip around methods like RR. Whenever you define a
-mock/stub method, you must provide the block immediately.
+The advantage of specifying mocks twice is that we could actually provide
+different results for each call. You could think of it as a stack. Here's
+a simple example:
 
 ``` ruby
-mock(object).foo{ 'bar' }.times(2)
+obj = Object.new
+mock(obj).name{ 0 }
+mock(obj).name{ 1 }
+mock(obj).name{ 2 }
+p obj.name     # 0
+p obj.name     # 1
+p obj.name     # 2
+p Muack.verify # true
 ```
 
-If unfortunately, the method name you want to mock is already defined,
-you can call `method_missing` directly to mock it. For example, `inspect`
-is already defined in `Muack::Mock` to avoid crashing with [Bacon][].
-In this case, you should do this to mock `inspect`:
+We could also use the block form for convenience:
 
 ``` ruby
-mock(object).method_missing(:inspect){ 'bar' }.times(2)
+obj = Object.new
+mock(obj) do |m|
+  m.name{ 0 }
+  m.name{ 1 }
+  m.name{ 2 }
+end
+p obj.name     # 0
+p obj.name     # 1
+p obj.name     # 2
+p Muack.verify # true
 ```
 
-#### [Stubbing method implementation / return value](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#stubbing-method-implementation--return-value)
-
-Again, we embrace one true API to avoid confusion, unless the alternative
-API really has a great advantage. So we encourage people to use the block to
-return values. However, sometimes you cannot easily do that for certain
-methods due to Ruby's syntax. For example, you can't pass a block to
-a subscript operator `[]`. As a workaround, you can do it with
-`method_missing`, though it's not very obvious if you don't know
-what is `method_missing`.
+Note that this does not apply to stubs because stubs never run out, thus
+making stubs defined later have no effects at all.
 
 ``` ruby
-stub(object).method_missing(:[], is_a(Fixnum)){ |a| a+1 }
-object[1]  #=> 2
+obj = Object.new
+stub(obj) do |m|
+  m.name{ 0 }
+  m.name{ 1 }
+  m.name{ 2 }
+end
+p obj.name     # 0
+p obj.name     # 0
+p obj.name     # 0
+p Muack.verify # true
 ```
 
-Instead you can do this with `returns`:
+Note that if you do not want a given method be called at all, you could
+use `times(0)` to enforce this.
+
+#### with_any_args
+
+We haven't talked about verifying arguments. With `with_any_args` modifier,
+we're saying that we don't care about the arguments. If we're not specifying
+any arguments like above examples, we're saying there's no arguments at all.
+
+Here we'll show an example for `with_any_args`. If you do want to verify some
+specific arguments, jump to _Arguments Verifiers_ section.
 
 ``` ruby
-stub(object)[is_a(Fixnum)].returns{ |a| a + 1 }
-object[1]  #=> 2
+obj = Object.new
+mock(obj).name{ 'obj' }.with_any_args.times(4)
+p obj.name       # 'obj'
+p obj.name(1)    # 'obj'
+p obj.name(nil)  # 'obj'
+p obj.name(true) # 'obj'
+p Muack.verify   # true
 ```
 
-You can also pass a value directly to `returns` if you only want to return
-a simple value.
+#### returns
+
+For some methods, we can't really pass a block to specify the implementation.
+For example, we can't pass a block to `[]`, which is a Ruby syntax limitation.
+To workaround it, we could use `returns` property:
 
 ``` ruby
-stub(object)[is_a(Fixnum)].returns(2)
-object[1]  #=> 2
+obj = Object.new
+mock(obj)[0].returns{ 0 }
+p obj[0]       # 0
+p Muack.verify # true
 ```
 
-On the other hand, since Muack is more strict than RR. Passing no arguments
-means you really don't want any argument. Here we need to specify the
-argument for Muack. The example in RR should be changed to this in Muack:
+This is also useful when we want to put the implementation block in the last
+instead of the beginning. Here's an example:
 
 ``` ruby
-stub(object).foo(is_a(Fixnum), anything){ |age, count, &block|
-  raise 'hell' if age < 16
-  ret = block.call count
-  blue? ? ret : 'whatever'
-}
+obj = Object.new
+mock(obj).name.times(2).with_any_args.returns{ 'obj' }
+p obj.name     # 'obj'
+p obj.name     # 'obj'
+p Muack.verify # true
 ```
 
-#### [Stubbing method implementation based on argument expectation](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#stubbing-method-implementation-based-on-argument-expectation)
+On the other hand, there's also another advantage of using `returns` than
+passing the block directly to the injected method. With `returns`, there's
+an additional option we could use by passing arguments to `returns`. We
+can't do this in regular injected method definition because those arguments
+are for verifying the actual arguments. Jump to _Arguments Verifiers_ section
+for details.
 
-Here is exactly the same as RR.
+The only option right now is `:instance_exec`.
 
-``` ruby
-stub(object).foo { 'bar' }
-stub(object).foo(1, 2) { 'baz' }
-object.foo        #=> 'bar'
-object.foo(1, 2)  #=> 'baz'
-```
+#### instance_exec mode
+
+By default, the block passed to the injected method is lexically/statically
+scoped. That means, the scope is bound to the current binding. This is the
+default because usually we don't need dynamic scopes, and we simply want to
+return a plain value, and this is much easier to understand, and it is the
+default for most programming languages, and it would definitely reduce
+surprises. If we really need to operate on the object, we have it, and
+we could touch the internal by calling instance_eval on the object.
 
-#### [Stubbing method to yield given block](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#stubbing-method-to-yield-given-block)
+However, things are a bit different if we're using `any_instance_of`.
+If we're using `any_instance_of`, then we don't have the instance at
+hand at the time we're defining the block, but only a `Muack::AnyInstanceOf`
+instance to represent the instance. There's no way we could really touch
+the object without `instance_exec` option.
 
-Always use the block to pass whatever back.
+This would also be extremely helpful if we're using Muack as a monkey
+patching library. We don't have to copy the original codes in order to
+monkey patching a class, we could simply inject what we really want to
+fix the internal stuffs in the broken libraries we're using. Jump to
+_Muack as a mocky patching library_ section for more detail.
+
+Here's an quick example:
 
 ``` ruby
-stub(object).foo{ |&block| block.call(1, 2, 3) }
-object.foo {|*args| args } # [1, 2, 3]
+any_instance_of(Array) do |array|
+  p array.class # Muack::AnyInstanceOf
+  mock(array).name.returns(:instance_exec => true){ inspect }
+end
+p [0, 1].name   # '[0, 1]'
+p Muack.verify  # true
 ```
 
-#### [Expecting method to be called with exact argument list](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-be-called-with-exact-argument-list)
+Note that this `:instance_exec` option also applies to other modifiers which
+accepts a block for its implementation, i.e. `peek_args` and `peek_return`.
+
+#### peek_args
 
-Muack is strict, you always have to specify the argument list.
+What if we don't really want to change an underlying implementation for a
+given method, but we just want to slightly change the arguments, or we
+might just want to take a look at the arguments? Here's an example using
+`peek_args` to modify the original arguments.
+
+Note that here we use the proxy mode for the mock, because if we're defining
+our own behaviour, then we already have full control of the arguments.
+There's no points to use both. This also applies to `peek_return`.
 
 ``` ruby
-mock(object).foo(1, 2)
-object.foo(1, 2)   # ok
-object.foo(3)      # fails
+str = 'ff'
+mock(str).to_i.with_any_args.peek_args{ |radix| radix * 2 }
+p str.to_i(8)  # 255
+p Muack.verify # true
 ```
 
-Passing no arguments really means passing no arguments.
+`peek_args` also supports `:instance_exec` mode. Here's an example:
 
 ``` ruby
-stub(object).foo
-stub(object).foo(1, 2)
-object.foo(1, 2)   # ok
-object.foo         # ok
-object.foo(3)      # fails
+any_instance_of(Array) do |array|
+  stub(array).push.with_any_args.
+    peek_args(:instance_exec => true){ |_| size }
+end
+a = []
+p a.push.dup   # [0]
+p a.push.dup   # [0, 1]
+p a.push.dup   # [0, 1, 2]
+p Muack.verify # true
 ```
 
-#### [Expecting method to be called with any arguments](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-be-called-with-any-arguments)
+We could also omit `|_|` if we don't care about the original argument
+in the above example.
 
-Muack also provides `with_any_args` if we don't really care.
+#### peek_return
+
+What if we don't really want to change an underlying implementation for a
+given method, but we just want to slightly change the return value, or we
+might just want to take a look at the return? Here's an example using
+`peek_return` to modify the original return value.
 
 ``` ruby
-stub(object).foo.with_any_args
-object.foo        # ok
-object.foo(1)     # also ok
-object.foo(1, 2)  # also ok
-                  # ... you get the idea
+str = 'ff'
+mock(str).to_i.with_any_args.peek_return{ |int| int * 2 }
+p str.to_i(16) # 510
+p Muack.verify # true
 ```
 
-#### [Expecting method to be called with no arguments](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-be-called-with-no-arguments)
-
-Just don't pass any argument :)
+`peek_return` also supports `:instance_exec` mode. Here's an example:
 
 ``` ruby
-stub(object).foo
-object.foo        # ok
-object.foo(1)     # fails
+any_instance_of(Array) do |array|
+  stub(array).push.with_any_args.
+    peek_return(:instance_exec => true){ |_| size }
+end
+a = []
+p a.push(0)    # 1
+p a.push(0)    # 2
+p a.push(0)    # 3
+p a            # [0, 0, 0]
+p Muack.verify # true
 ```
 
-#### [Expecting method to never be called](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-never-be-called)
+We could also omit `|_|` if we don't care about the original return value
+in the above example.
+
+### Arguments Verifiers (Satisfy)
+
+If we're not passing any arguments to the injected method we define, then
+basically we're saying that there's no arguments should be passed to the
+method. If we don't care about the arguments, then we should use
+`with_any_args` modifier. If we want the *exact* arguments, then we
+should just pass the arguments, which would be checked with `==` operator.
 
-Simply use `times(0)`.
+Here's an example:
 
 ``` ruby
-mock(object).foo.times(0)
-object.foo        # fails
+obj = Object.new
+mock(obj).say('Hi'){ |arg| arg }
+p obj.say('Hi') # 'Hi'
+p Muack.verify  # true
 ```
 
-Multiple mock with different argument set is fine, too.
+This also applies to multiple arguments:
 
 ``` ruby
-mock(object).foo(1, 2).times(0)
-mock(object).foo(3, 4)
-object.foo(3, 4)  # ok
-object.foo(1, 2)  # fails
+obj = Object.new
+mock(obj).say('Hello', 'World'){ |*args| args.join(', ') }
+p obj.say('Hello', 'World') # 'Hello, World'
+p Muack.verify  # true
 ```
 
-#### [Expecting method to be called only once](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-be-called-only-once)
+We could also retrieve the block argument:
 
-By default, a mock only expects a call. Using `times(1)` is actually a no-op.
+``` ruby
+obj = Object.new
+mock(obj).say{ |&block| block.call('Hi') }
+obj.say{ |msg| p msg } # 'Hi'
+p Muack.verify  # true
+```
+
+Moreover, we could also have stubs on the same method for different
+arguments. We could think of this as a sort of pattern matching, and Muack
+would try to find the best matched stub for us.
 
 ``` ruby
-mock(object).foo.times(1)
-object.foo
-object.foo    # fails
+obj = Object.new
+stub(obj).find(0){ 0 }
+stub(obj).find(1){ 1 }
+p obj.find(1)  # 1
+p obj.find(0)  # 0
+p Muack.verify # true
 ```
 
-#### [Expecting method to called exact number of times](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-called-exact-number-of-times)
+If `obj.find(2)` is called and Muack cannot find a matched stub, it would
+raise a `Muack::Unexpected` and list the candidates for us.
+
+However, What if we don't want to be so exact? Then we should use verifiers.
+We'll introduce each of them in next section. Note that verifiers
+are not recursive though. If you need complex argument verification,
+you'll need to use `satisfy` verifier which you could give an arbitrary
+block to verify anything.
 
-Times! Which is the same as RR.
+#### is_a
+
+`is_a` would check if the argument is a kind of the given class.
+Actually, it's calling `kind_of?` underneath.
 
 ``` ruby
-mock(object).foo.times(3)
-object.foo
-object.foo
-object.foo
-object.foo    # fails
+obj = Object.new
+mock(obj).say(is_a(String)){ |arg| arg }
+p obj.say('something') # 'something'
+p Muack.verify         # true
 ```
 
-Alternatively, you could also do this. It's exactly the same.
+#### anything
+
+`anything` is a wildcard argument verifier. It matches anything.
+Although this actually verifies nothing, we could still think of
+this as an arity verifier. Since one anything is not two anythings.
 
 ``` ruby
-3.times{ mock(object).foo }
-object.foo
-object.foo
-object.foo
-object.foo    # fails
+obj = Object.new
+mock(obj).say(anything){ |arg| arg }.times(2)
+p obj.say(0)    # 0
+p obj.say(true) # true
+p Muack.verify  # true
 ```
 
-#### [Expecting method to be called minimum number of times](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-be-called-minimum-number-of-times)
+#### match
 
-It's not supported in Muack, but we could emulate it somehow:
+`match` would check the argument with `match` method. Usually this is
+used with regular expression, but anything which responds to `match`
+should work.
 
 ``` ruby
-times = 0
-stub(object).foo{ times += 1 }
-object.foo
-object.foo
-raise "BOOM" if times <= 3
+obj = Object.new
+mock(obj).say(match(/\w+/)){ |arg| arg }
+p obj.say('Hi') # 'Hi'
+p Muack.verify  # true
 ```
 
-#### [Expecting method to be called maximum number of times](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-be-called-maximum-number-of-times)
+Note that please don't pass the regular expression directly without
+wrapping it with a match verifier, or how do we distinguish if we
+really want to make sure the argument is exactly the regular expression?
 
+#### hash_including
 
-It's not supported in Muack, but we could emulate it somehow:
+`hash_including` would check if the given hash is the actual
+argument's subset.
 
 ``` ruby
-times = 0
-stub(object).foo{ times += 1; raise "BOOM" if times > 3 }
-object.foo
-object.foo
-object.foo
-object.foo
+obj = Object.new
+mock(obj).say(hash_including(:a => 0)){ |arg| arg }
+p obj.say(:a => 0, :b => 1) # {:a => 0, :b => 1}
+p Muack.verify # true
 ```
 
-#### [Expecting method to be called any number of times](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#expecting-method-to-be-called-any-number-of-times)
+#### including
 
-Just use `stub`, which is exactly why it is designed.
+`including` would check if the actual argument includes the given value
+via `include?` method.
 
 ``` ruby
-stub(object).foo
-object.foo
-object.foo
-object.foo
+obj = Object.new
+mock(obj).say(including(0)){ |arg| arg }
+p obj.say([0,1]) # [0,1]
+p Muack.verify   # true
 ```
 
-#### [Argument wildcard matchers](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#argument-wildcard-matchers)
+#### within
 
-`anything` is the same as RR.
+`within` is the reverse version of `including`, verifying if the actual
+argument is included in the given value.
 
 ``` ruby
-mock(object).foobar(1, anything)
-object.foobar(1, :my_symbol)
+obj = Object.new
+mock(obj).say(within([0, 1])){ |arg| arg }
+p obj.say(0)   # 0
+p Muack.verify # true
 ```
 
-`is_a` is the same as RR.
+#### respond_to
+
+`respond_to` would check if the actual argument would be responding to
+the given message, checked via `respond_to?`, also known as duck typing.
 
 ``` ruby
-mock(object).foobar(is_a(Time))
-object.foobar(Time.now)
+obj = Object.new
+mock(obj).say(respond_to(:size)){ |arg| arg }
+p obj.say([])  # []
+p Muack.verify # true
 ```
 
-No numeric supports. Simply use `is_a(Numeric)`
+Note that you could give multiple messages to `respond_to`.
 
 ``` ruby
-mock(object).foobar(is_a(Numeric))
-object.foobar(99)
+obj = Object.new
+mock(obj).say(respond_to(:size, :reverse)){ |arg| arg }
+p obj.say([])  # []
+p Muack.verify # true
 ```
 
-No boolean supports, but you can use union (`|`).
+#### satisfy
+
+`satisfy` accepts a block to let you do arbitrary verification.
+nil and false are considered false, otherwise true, just like in
+regular if expression.
 
 ``` ruby
-mock(object).foobar(is_a(TrueClass) | is_a(FalseClass))
-object.foobar(false)
+obj = Object.new
+mock(obj).say(satisfy{ |arg| arg % 2 == 0 }){ |arg| arg }
+p obj.say(0)   # 0
+p Muack.verify # true
 ```
 
-Since duck_type is a weird name to me. Here we use `respond_to(:walk, :talk)`.
+#### Disjunction (|)
+
+If what we want is the actual argument be within either `0..1` or `3..4`?
+We don't really have to use `satisfy` to build custom verifier, we could
+compose verifiers with disjunction operator (|).
 
 ``` ruby
-mock(object).foobar(respond_to(:walk, :talk))
-arg = Object.new
-def arg.walk; 'waddle'; end
-def arg.talk; 'quack'; end
-object.foobar(arg)
+obj = Object.new
+mock(obj).say(within(0..1) | within(3..4)){ |arg| arg }.times(2)
+p obj.say(0)   # 0
+p obj.say(4)   # 4
+p Muack.verify # true
 ```
 
-You can also use intersection (`&`) for multiple responses.
-Though there's not much point here. Just want to demonstrate.
+Or boolean, you might say:
 
 ``` ruby
-mock(object).foobar(respond_to(:walk) & respond_to(:talk))
-arg = Object.new
-def arg.walk; 'waddle'; end
-def arg.talk; 'quack'; end
-object.foobar(arg)
+obj = Object.new
+mock(obj).say(is_a(TrueClass) | is_a(FalseClass)){ |arg| arg }.times(2)
+p obj.say(true)  # true
+p obj.say(false) # false
+p Muack.verify   # true
 ```
 
-Don't pass ranges directly for ranges, use `within`. Or how do we tell
-if we really want the argument to be a `Range` object?
+#### Conjunction (&)
+
+If what we want is the actual argument not only a kind of something,
+but also responds to something. For example, an Enumerable requires the
+class implements each method. We could use conjunction for this.
 
 ``` ruby
-mock(object).foobar(within(1..10))
-object.foobar(5)
+obj = Object.new
+mock(obj).say(is_a(Enumerable) & respond_to(:each)){}.times(3)
+p obj.say( [] ) # nil
+p obj.say( {} ) # nil
+p obj.say(0..1) # nil
+p Muack.verify  # true
 ```
 
-The same goes to regular expression. Use `match` instead.
+### Caveat
+
+#### Mixing mocks and stubs
+
+We could and probably would also want to mix mocks and stubs, for example,
+we might be concerned about some methods for a given object, but not the
+other methods.
 
 ``` ruby
-mock(object).foobar(match(/on/))
-object.foobar("ruby on rails")
+obj = Object.new
+stub(obj).name{ 'obj' }
+mock(obj).id  { 12345 }
+p obj.name     # 'obj'
+p obj.name     # 'obj'
+p obj.id       # 12345
+p Muack.verify # true
 ```
 
-`hash_including` is the same as RR.
+However, it might act unexpectedly if we mock and stub on the same object
+for the same method. It would somehow act like the latter would always win!
+So if we define mock later for the same method, previously defined stub
+would never be called. On the other hand, if we define stub later for the
+same method, previously defined mock would always complain because it would
+never be called, either!
+
+This does not mean previously defined mocks or stubs get overwritten, because
+it would still take effect. It's just that there's no way they could get
+called. So this is mostly not desired.
+
+The ideal solution to this would be raising an error immediately, or really
+make it could be overwritten. However I didn't find a good way to handle this
+without rewriting the internal details. So I'll just leave it as it is,
+and hope no one would ever try to do this.
+
+#### any_instance_of shares all calls for a given class
+
+We might assume that mocks with any_instance_of would work exactly the same
+as regular mocks, but this is actually not the case. Regular mocks count
+on every individual instance, but all instances share the same count for
+any_instance_of.
+
+With one instance:
 
 ``` ruby
-mock(object).foobar(hash_including(:red => "#FF0000", :blue => "#0000FF"))
-object.foobar({:red => "#FF0000", :blue => "#0000FF", :green => "#00FF00"})
+any_instance_of(Array){ |array| mock(array).f{true}.times(2) }
+a = []
+p a.f          # true
+p a.f          # true
+p Muack.verify # true
 ```
 
-`satisfy` is the same as RR.
+With two instances:
 
 ``` ruby
-mock(object).foobar(satisfy {|arg| arg.length == 2 })
-object.foobar("xy")
+any_instance_of(Array){ |array| mock(array).f{true}.times(2) }
+p [].f         # true
+p [].f         # true
+p Muack.verify # true
+```
+
+So remember to count on all instances, but not individual ones.
+
+### Extra Topics
+
+#### Muack as a mocky patching library
+
+Consider you're using a broken library and you need an immediate fix without
+waiting for upstream to merge your patch, and release a new version.
+
+You could fix it more elegantly by subclassing the original class, or try to
+include or extend a module to make the original class work correctly. But
+sometimes we just cannot do this because of the implementation. They might
+not be extensible at all. Consider if there's a method contains 1,000
+lines... There's no way to change it in the middle of the method other than
+touching the lines directly, unless we have some line based AOP tools...
+which is not really practical.
+
+In this case, we could fork it and maintain everything by ourselves, and
+merge from upstream occasionally. However we might only want to do this as
+the last resort since this could cost a lot.
+
+Alternatively, we can copy the original code, and put it somewhere, and
+load it after the original code was loaded, so we have the patched and
+correct code running. This is also called monkey patching, patching like a
+monkey. Generally this is a bad idea, but sometimes we can only do this to
+workaround some broken libraries. For example, some libraries might not be
+maintained, or the authors refused to fix this due to other reasonable or
+unreasonable reason.
+
+The most notable drawback of monkey patching is that, we're copying a lot of
+codes which could be changed upstream, and we might not be aware of that,
+and update our monkey patch accordingly. This could cause some incompatible
+issues.
+
+That means, the fewer copied codes, the better. Muack could actually help
+in this case. I called this mocky patching. The advantage of using this
+technique is that, we have `peek_args` and `peek_return` which we could
+modify the arguments or return values in runtime, without changing any
+implementation of a particular method.
+
+Here's a real world example with rails_admin. The problem in rails_admin is
+that, it assumes every associated records should have already been saved,
+thus having an id, and there's also a particular show page for it.
+
+However, in our application, we could have associated records not yet saved
+in the database. rails_admin would try to retrieve routes for those unsaved
+records, and rails would raise RoutingError because rails_admin is passing
+no id for a show path.
+
+The idea of this fix is simple. Just don't try to get the show page for
+records which are not yet saved, i.e. records without an id. However this
+is actually extremely hard to fix in rails_admin without monkey patching!
+
+I'll skip all those details and my rants. In the end, I fixed this by
+trying to peek the arguments for a particular method, and if and only if
+the passed records are not yet saved in the database, we fake the arguments.
+Otherwise, we just bypass and fallback to the original implementation.
+
+Here's the code:
+
+```  ruby
+Muack::API.stub(RailsAdmin::Config::Actions).find.with_any_args.
+  peek_args do |*args|
+    custom_key, bindings = args
+    if bindings && bindings[:object] && bindings[:object].id.nil?
+      [nil, {}] # There's no show page for unsaved records
+    else
+      args # Bypass arguments
+    end
+  end
+```
+
+If we don't do mocky patching but monkey patching, we'll end up with
+copying the entire method for RailsAdmin::Config::Actions.find, which then,
+we'll be responsible for updating this method if some of the original
+implementation changed.
+
+Note that in mocky patching, we should always use stub and never call
+`Muack.verify` or `Muack.reset`, or that would defeat the purpose of
+mocky patching.
+
+#### Muack as a development runtime static typing system
+
+Ever consider a static type system in Ruby? You could actually see a lot of
+asserts inserted in the beginning of some methods in some libraries. For
+example, there are `assert_valid_key_size`, `assert_kind_of`, etc, in
+[dm-core][], and `assert_valid_keys`, `assert_valid_transaction_action`,
+and various random asserts in activerecord.
+
+You could find them by searching against `raise ArgumentError` because
+rails is much less consistent and sometimes it's hard to find a pattern in
+rails. But you get the idea, those `ArgumentError` would much help us debug
+our code from misusing the API, and that's exactly the point of type system,
+or more specifically, static type system.
+
+We could also use some static analysis tools to do something like this, for
+example, there's [ruby-lint][]. However, as you might already know, since
+Ruby is so dynamic, static analysis tools cannot really do a great job if
+our code is quite dynamic. Of course we could write it more statically,
+and treat our static analysis tools better, but that might not be the spirit
+of Ruby somehow.
+
+Alternatively, it would be great to do this static type checking
+dynamically... I mean, in the runtime rather than compile time. This
+means it would be much more accurate, just like those asserts in the
+above examples.
+
+However, if we're doing those checks in a hot path, for example, right
+inside a loop looping over a million times, this would definitely slow
+things down if we're checking them in the runtime. Even if we put `$DEBUG`
+guards around those check, we're still suffering from checking the flag.
+
+It would be great if we could actually just remove those checks in
+production, while turn it on when we're developing or debugging.
+Muack could actually fulfill this desire, as it could inject codes
+externally and seamlessly, and we could remove them anytime when we
+call `Muack.reset`, or, simply don't do any stubs in production config.
+
+Consider we have two classes:
+
+```  ruby
+Food = Class.new
+User = Class.new{ attr_accessor :food }
+```
+
+And we could make sure User#food is always a kind of `Food` by putting this
+into a development config or so:
+
+```  ruby
+Muack::API.module_eval do
+  any_instance_of(User) do |user|
+    stub(user).food = is_a(Food)
+  end
+end
 ```
 
-#### [Writing your own argument matchers](https://github.com/rr/rr/blob/e4b4907fd0488738affb4dab8ce88cbe9fa6580e/doc/03_api_overview.md#writing-your-own-argument-matchers)
+And then if we're trying to set a food other than a `Food`...
+
+```  ruby
+u, f = User.new, Food.new
+u.food = f # ok
+u.food = 1 # raise Muack::Unexpected
+```
 
-See [`lib/muack.rb`][muack.rb] and [`lib/muack/satisfy.rb`][satisfy.rb],
-you would get the idea soon. Here's how `is_a` implemented.
+This could go wild and we could customize our own domain specific argument
+verifiers. For example, we could do this to check if the food is frozen:
 
 ``` ruby
-module Muack::API
-  module_function
-  def is_a klass
-    Muack::IsA.new(klass)
+Food = Class.new
+User = Class.new{ attr_accessor :food }
+
+FoodFrozen = Class.new(Muack::Satisfy) do
+  def initialize
+    super lambda{ |actual_arg| actual_arg.frozen? }
   end
 end
 
-class Muack::IsA < Muack::Satisfy
-  def initialize klass
-    super lambda{ |actual_arg| actual_arg.kind_of?(klass) }, [klass]
+Muack::API.module_eval do
+  any_instance_of(User) do |user|
+    stub(user).food = FoodFrozen.new
   end
 end
+
+u = User.new
+p u.food = Food.new.freeze # ok
+p u.food = Food.new        # raise Muack::Unexpected
 ```
 
-[muack.rb]: https://github.com/godfat/muack/blob/master/lib/muack.rb
-[satisfy.rb]: https://github.com/godfat/muack/blob/master/lib/muack/satisfy.rb
+Please check _Arguments Verifiers (Satisfy)_ section for more argument
+verifiers details.
+
+[dm-core]: https://github.com/datamapper/dm-core
+[ruby-lint]: https://github.com/YorickPeterse/ruby-lint
 
 ## USERS:
 
@@ -561,7 +1008,7 @@ end
 
 Apache License 2.0
 
-Copyright (c) 2013, Lin Jen-Shin (godfat)
+Copyright (c) 2013~2014, Lin Jen-Shin (godfat)
 
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.