It's unlikely but possible that an exception may be raised in `Mockery#teardown`. We should ensure that the `Mockery` instance gets reset if this happens. I'm not really happy with the way the test works, but without major changes this is the best I can do for now. Fixes #144. I saw this while investigating #142.
It is possible for `Module#public`, `#protected` and `#private` to be redefined on descendant classes, so it' safer to use the original version of these methods on `Module` when restoring the visibility of stubbed methods. Rather than add a completely new set of tests for these scenarios, I have just embellished the existing tests. It's not ideal, because it makes it less clear what's going on, but I think it'll do.
The Mocha integration tests are unfortunately dependent on the exact format of the test results output by MiniTest. This means that since the format changed in MiniTest v4.6.1, we have to change the regular expressions used to parse the output. It would be nicer to use named capture groups for the regular expression, but these only appear to be available in Ruby >= v1.9.
This change is specifically to cope with the nasty re-defining of classes that is done by the `minitest-spec-rails` gem . This confuses the Test::Unit version detection logic in Mocha and it thinks that the Ruby 1.8 standard library version of Test::Unit is being used when in fact there is no Test::Unit version present. I'm not completely sure why this has reared its head  with Rails 4 and/or Ruby 2, and haven't checked carefully that this change is (a) completely logical; and (b) hasn't introduced any regressions, but it does seem to fix the problem. I'm going to push it now and try to track down any regressions separately - I'm pretty hopeful there won't be any. Note that it will be possible to avoid this problem in the future when we introduce the ability to manually activate specific test library integration and stop using the automatic activation.  metaskills/minitest-spec-rails#17  freerange#143
Use `require` instead of `load` with `test/unit/version`. Other gems also require `test/unit/version`. When mocha loads the same file it over writes the constant and causes a warning. I tried to reproduce the original problem  with more recent versions of the test-unit and mocha gems, but I ran into a different exception. This exception was fixed by adding a `gem "test-unit"` statement before the `require "test/unit"` statement.  http://floehopper.lighthouseapp.com/projects/22289-mocha/tickets/50#ticket-50-13
Other gems also require test/unit/version. When this gem loads the same file it over writes the constant and causes a warning.
We were only testing stubbing of the public and protected methods on Object. Note that `#method_defined?` and `#instance_methods` include both public and protected, but not private methods. There are still a few methods that are awkward, but I've just excluded them from the tests for now. There's probably a better solution to this in 1.9 involving inheriting Mock from BasicObject instead of Object, but that's a job for another day.
I prefer unabbreviated variable names.
@voxik wanted to run the tests by simply requiring the files rather than running the rake task. If the unit tests and acceptance tests are loaded in the same process and if a recent version of MiniTest is available, then `ExpectationErrorFactory.exception_class` was being set to `MiniTest::Assertion` at file load time and then later when the unit tests ran, the latter exception was being raised instead of the default `ExpectationError` exception. This causes a number of unit tests to fail. I have fixed this by changing the assertions to expect `ExpectationErrorFactory.exception_class`. I've also had to change `ExpectationErrorFactory.exception_class` to be set to the default at file load time to make this work.
Given a method which is re-declared with a different visibility lower down the ancestor chain, and given we stub the "version" of the method that is lower down the ancestor chain, we should ensure it is restored to its original visibility when it is "unstubbed". This was highlighted in #109 where the FileUtils module in Ruby 2.0 declares the module-instance methods as private and then re-declares the module-class methods as public . Even though this bug was highlighted in Ruby 2.0, it can happen in Ruby 1.8 or 1.9 if methods are declared in the same way. We've added a new acceptance test to demonstrate the bug and fixed it. The fix is to store and restore the method visibility whether or not we remove the stubbed method. Note that in Ruby 1.8.7 there is a warning about re-defining the method, but we can't see an easy way around this at the moment.  ruby/ruby@ace4630#L1R161
This is useful if you have a class that is awkward to instantiate. The implementation uses `Class#allocate` to instantiate the responder _without_ calling the class' `#initialize` method. Having built the responder instance, the implementation is the same as for `Mock#responds_lie`. Thanks to @simao for the original suggestion.
Elsewhere we are using `# =>` to display the expected output and not using `Test::Unit::Assertions`.
- I don't abbreviated variable names or variable names with digits in them, so I've got rid of `param_1`. - I've used some more case statements to simplify the code and hopefully make it more obvious what's going on. This also helped me find another edge case that we'd missed. See next bullet point. - Raise an argument error when someone supplies a single argument that is not a Hash. - Use some idiomatic Ruby to assign `key` & `value` in a single simpler statement. - Added a test for the case where more than two arguments are supplied and an argument error is raised.
I suspect there may be a lot of libraries out there that are requiring "mocha" directly will now be generating deprecation warnings. This should make it easier to find them.