There have been no changes to mock.rb since we last updated it: https://github.com/freerange/mocha/blob/v0.13.0/lib/mocha/mock.rb
*** Mocha deprecation warning: Test::Unit or MiniTest must be loaded *before* Mocha.
*** Mocha deprecation warning: If you're integrating with a test library other than Test::Unit or MiniTest, you should use `require 'mocha/api'` instead of `require 'mocha'`.
Looks good to me.
General note for anyone seeking a temporary workaround: I was able to get rid of these warnings by using gem 'bourne', require: false in my Gemfile and require 'bourne' in my spec/spec_helper.rb in the current version of Bourne.
gem 'bourne', require: false
Bourne is currently at 1.2.1 - is this a minor (1.2.2) or major (1.3.0) bump?
Since switching from mocha 0.12.3 -> 0.12.7 was a minor bump, I think this should be as well.
Looks like you need at least RSpec 2.12.0 to use Mocha 0.13.0:
I think that's fine.
Depend on mocha 0.13.0
* Change to `require "mocha/setup"` per release notes for 0.13.0:
Any reason not to specify the dependency using Pessimistic Version Constraint (a.k.a. the ~> operator)?
@sferik Mocha doesn't explicitly follow SemVer and historically it's been hit and miss when it comes to things breaking; we're erring on the side of caution by using an explicit version requirement for the time being. It means we have to update more often but that means the software should always work properly, which is our goal at the end of the day!
Fair enough. Personally, I'd rather spend the time and effort that would be spent updating more often to explain the virtues of SemVer to the maintainers of Mocha. If, for some reason, they are unwilling (or unable) to follow SemVer, I'd start looking for an alternative mocking framework.
@sferik while I understand the logic, Mocha is a great framework and one we love using; additionally, we've tried explaining the benefits of spying versus setting up expectations to the maintainer and he's continually rejected our requests to get this into Mocha proper. We're stuck between a rock and a hard place and have chosen to lock to versions of Mocha as a coping mechanism. While it's not eloquent, it allows us to move forward and get work done without being too coupled to how the maintainer(s) of Mocha decide to release their gem.
The SemVer issue is totally separate; I personally don't have the time to explain it to him right now, but yeah, I understand what you're saying. Maybe after the holidays are over I'd be able to ping the maintainer(s) and see what they think. I know RSpec's been coping with their versioning for a while too...
I think the Ruby community would benefit from and appreciate a thoughtbot fork of Mocha, even if it just added spying and a sane versioning policy.
For what it's worth, I've been adding a simple versioning statement to the repositories that I contribute to, in order to promote the use of SemVer (or, for that matter, any sane versioning policy) across the Ruby gem ecosystem.
My biggest gripe with Mocha is that it has been around since 2006 but has still yet to define a stable, public 1.0 API.
@sferik agree re: a stable API. I've thought about forking/standardizing but maintaining a fork is never fun. I'd be interested in hearing what the goals are for a 1.0 release (if they have one) and contributing to that in hopes that it'll be a more reasonable time to adopt SemVer (since anything pre-1.0 is technically fair game to be mangled or hacked).
The mocha authors mentioned that they're open to a pull request that would add hooks for bourne, assuming that the hooks themselves aren't crappy in some way. I don't think we need too much, but I've never had time to look into it.
@jferris @joshuaclayton The strict dependency creates a problem when other gems depend on bourne, e.g. shoulda-matchers. Now I am stuck with mocha 0.12 until bourne releases the 0.13.1 mocha dependency update and shoulda-matchers in turn updates the dependency on bourne. It is a very strange loop, which really doesn't make sense to me.
Also - I am stealing @sferik's sem ver note for my repos.
Right - the strict dependency is definitely annoying, but due to the current implementation, a loose dependency reliably will cause broken combinations. Reworking the interaction between bourne/mocha to be less intrusive will allow us to loosen this.