Since all but the very earliest releases are tagged in the git repository, these serve no useful purpose, make the release notes look ugly in YARD, and add to the work needed for a release.
- Converting the original method to a `Proc` meant we lost the block parameter in the restored version of the method. - Hopefully this fixes #76.
Since Ruby 1.9.3 includes much later versions of MiniTest, excluding these doesn't seem to lose much value.
It seems like this is somehow backwardly compatible, but I haven't investigated closely. It may cause CI failures.
- This brings it into line with ClassMethod & InstanceMethod which were changed in 1802fb936bc5a0cae46458b5f7e5b69e9dea6616. Storing the method in an instance variable seems like a more elegant solution and has the advantage of not changing the stubbed object's interface, albeit with an obfuscated method name. - As in ClassMethodTest, many tests in AnyInstanceTest are no longer appropriate for the new implementation and like many of the unit tests are in any case way too implementation-specific. - It should now be possible to remove ClassMethod#hidden_method, which was only being used by AnyInstanceMethod.
- Instead of hiding the original method using alias_method, we can store it as an instance variable and re-define it later if appropriate. - Although all the tests are passing at this point, the tests in ClassMethodTest aren't all appropriate for the new implementation. In fact they are (like many of the unit tests) way too implementation-specific. - We also need to convert AnyInstanceMethod to work the same way. It should then be possible to remove ClassMethod#hidden_method.
And in any case this doesn't work with MiniTest.
- It seems very unlikely that anyone would ever intentionally stub a method on `nil`, since the instance of NilClass is effectively a singleton and stubbing a method will affect all "instances" of `nil`. - It is still possible to stub methods on `nil` by modifying the default `Configuration` setting for `:stubbing_method_on_nil`. - This should hopefully address some of the problems raised in #68.
- Since we will not be able to define a new method on the frozen object, it's better to fail fast and avoid leaving things in a bad state e.g. having hidden the original method. - Using the existing StubbingError seems appropriate and has the advantage of ensuring the backtrace points at the point where the stubbing was attempted. - This should hopefully address some of the issues in #68.