Permalink
Browse files

Depend on mocha 0.13.0

* Change to `require "mocha/setup"` per release notes for 0.13.0:
  http://gofreerange.com/mocha/docs/file.RELEASE.html
  • Loading branch information...
1 parent b81aa1a commit 298b30ce8ac974e00e1be77378337ff62e0e216b @gabebw gabebw committed with joshuaclayton Nov 26, 2012
View
@@ -20,7 +20,7 @@ Gem::Specification.new do |s|
s.executables = `git ls-files -- bin/*`.split("\n").map{ |f| File.basename(f) }
s.require_paths = ["lib"]
- s.add_dependency('mocha', '0.12.7') # follow instructions in mock.rb to update
+ s.add_dependency('mocha', '0.13.0') # follow instructions in mock.rb to update
@sferik
sferik Dec 1, 2012

Any reason not to specify the dependency using Pessimistic Version Constraint (a.k.a. the ~> operator)?

@joshuaclayton
joshuaclayton Dec 1, 2012 Member

@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!

@sferik
sferik Dec 1, 2012

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.

@joshuaclayton
joshuaclayton Dec 3, 2012 Member

@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...

@sferik
sferik Dec 3, 2012

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.

@joshuaclayton
joshuaclayton Dec 3, 2012 Member

@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).

@jferris
jferris Dec 5, 2012 Member

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.

@pboling
pboling Jan 8, 2013

@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.

@jferris
jferris Jan 11, 2013 Member

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.

s.add_development_dependency('rake')
end
View
@@ -1,2 +1,2 @@
-require 'mocha'
+require 'mocha/api'
require 'bourne/api'
@@ -1,5 +1,5 @@
require File.expand_path('../../test_helper', __FILE__)
-require 'mocha'
+require 'mocha/setup'
class MochaExampleTest < Test::Unit::TestCase
@@ -1,5 +1,5 @@
require File.expand_path('../../test_helper', __FILE__)
-require 'mocha'
+require 'mocha/setup'
class Widget
View
@@ -14,7 +14,7 @@
end
require 'test/unit'
-require 'mocha'
+require 'mocha/setup'
if defined?(MiniTest)
FailedAssertion = MiniTest::Assertion
@@ -2,7 +2,7 @@
require 'test_runner'
require 'bourne/api'
require 'bourne/mockery'
-require 'mocha/object'
+require 'mocha/api'
class AssertReceivedTest < Test::Unit::TestCase
@@ -2,7 +2,7 @@
require 'test_runner'
require 'bourne/api'
require 'bourne/mockery'
-require 'mocha/object'
+require 'mocha/api'
require 'matcher_helpers'
module HaveReceivedTestMethods

0 comments on commit 298b30c

Please sign in to comment.