[rspec-users] Assumption tests

Daniel Tenner daniel.ruby at tenner.org
Sat Oct 20 18:49:27 EDT 2007

On 20 Oct 2007, at 19:54 20 Oct 2007, Pat Maddox wrote:
> You seem to believe that the only way to define behavior is in terms
> of interactions with other objects.  That is flat-out wrong.  Please
> read http://martinfowler.com/articles/mocksArentStubs.html.

Thanks for that excellent link. I hadn't read it yet. I need to think  
some more :-)

I think one of the reasons I've tended towards all-out behaviour  
mocking is that when you start mocking expectations, you often break  
outcome-based testing. As a good example, using another variation of  
that Account object...

class Account
   def initialize(balance_holder)
     @balance_holder = balance_holder

   def balance

   def withdraw(amount)
     @balance_holder.decrease_by amount

Now if @balance_holder is a pretty complex, slow object that cries  
out to be mocked, trying to test in the way that you suggested breaks  

it "should decrease the balance when an amount is withdrawn" do
   account = Account.new(@mock_balance_holder)

In a case like this, it seems to me impossible to avoid specifying  
only behaviour, unless you actually create a full-on fake object to  
fake the behaviour of the balance_holder (which could be a bit less  
trivial than this). But if you've mocked the balance_holder like  
that, it is impossible to then test the state of the Account.

I guess the issue comes from situations where the apparently internal  
state of an object is dependent on the state of another object. In my  
case, I have this happen fairly often when my facebook users, which  
depend on a nasty, bug-eyed facebook_session object that I definitely  
don't want to interact with in my specs (at least not with the real  
version, which is horrendously slow and bug-prone due to various  
facebook peculiarities). I don't think that's wrong design, but it  
does mean that in those cases you can't use outcome-testing at all  
(unless you are writing an integration test).

I'm all for pragmatism but it kind of irks me that I'd have to test  
behaviours in some cases and outcomes in others. I suppose neither of  
them is black nor white, and David's suggestion that it's all down to  
balancing design forces on a case-by-case basis...

Maybe I should get back into maths, so I can have some absolute  
truths again ;-)

Thanks to everyone for the very useful discussion, by the way. This  
is very helpful, and I'll try to summarize this thought progression  
on my blog so that it's not lost...


More information about the rspec-users mailing list