#69 ✓resolved
James Mead

Allow unstubbing of methods

Reported by James Mead | August 9th, 2010 @ 09:56 AM

Generated out of discussion on http://floehopper.lighthouseapp.com/projects/22289/tickets/68-durin...

It should be possible to do something like the following :-

  def test_me
    Time.stubs(:now).returns(Time.parse("2010-01-01 00:00"))
    # do stuff
    Time.unstubs(:now)
  end

Questions :-

  1. Should it be Object#unstubs or Object#unstub?
  2. What happens if there are multiple stubs for a given method e.g. 2 different "with" clauses? Presumably both stubs are reverted...?
  3. Should this work for a traditional mock object as well as for non-mock objects. It doesn't seem so relevant, but maybe it would be inconsistent not to...?
  4. Should it be possible to call this on a method that has an expectation (i.e. where #expects has been called)? What are the implications for that expectation i.e. should it still be satisfied for the test to pass...?

Comments and changes to this ticket

  • Deleted User

    Deleted User August 9th, 2010 @ 04:58 PM

    1. I should mention that I was not able (with almost no effort) to implement unstub_any
    2. I would expect both to revert
    3. Dunno
    4. My expectation would be that the moment you unstub, all your expectations should have been met.
  • Jamie Phelps

    Jamie Phelps October 13th, 2010 @ 05:49 PM

    I was looking for this exact functionality for unstubbing from any_instance and I think that providing at least a block-enabled variant is the way to go. Here are my answers:

    I think stubs method is good because it's accepting a hash. It could almost be written as stubs= afaiac.

    I think unstub is a transitive method as in "unstub this method" so, I think it should be unstub(*methods)

    Yes, I'd say unstub all stubs of a method. If folks felt strongly, a variant could be added that accepts an array or hash of with options for further targeting.

    Not sure about 3. Maybe I don't properly understand the question.

    Agree with kwerle on 4.

  • Alex

    Alex October 17th, 2010 @ 05:40 PM

    I created a fix for this - http://github.com/alexheaton/mocha (alexheaton/unstubs or master branches)

    I'd really welcome some feedback, I'm sure there are things that need improving. For instance, I may have missed some testing edge cases, or perhaps my tests are dirty (I normally use RSpec).

  • James Mead

    James Mead October 22nd, 2010 @ 05:05 PM

    I think this message [1] from Adam Cigánek on the Mocha mailing list is also relevant here.

    [1] http://groups.google.com/group/mocha-developer/browse_thread/thread...

  • James Mead

    James Mead November 12th, 2010 @ 01:19 PM

    • State changed from “new” to “open”
  • James Mead

    James Mead November 12th, 2010 @ 02:38 PM

    • State changed from “open” to “resolved”

    I've just pushed up changes to add Mocha::ObjectMethods#unstub. So I'm closing this ticket.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

A mocking & stubbing library for Ruby.

* <a href="http://github.com/floehopper/mocha">GitHub repository</a>
* <a href="http://mocha.rubyforge.org">Documentation</a>
* <a href="http://groups.google.com/group/mocha-developer">Mailing List</a>

People watching this ticket

Tags

Referenced by

Pages