I got a happy, lightweight solution to this. Due to excellent encapsulation (mainly thanks to using cucumber & rspec to drive development -- preach, geek!), there were two calls to my HTTParty service, which is called Salesforce::Service, and they were in the same class. So I created a private method in that class like follows:
def salesforce_service Salesforce::Service end and replaced the class name in my code with this method. I then override this method in a cuke env file to return a class called Salesforce::TestDecoratedService, which is, as the name suggests, a decorated version of the service that inherits Salesforce::Service. This simply records the call and parameters in an attribute called calls, then calls super to let Salesforce::Service do its thing. I then petition the calls parameter to confirm what happened. Can't believe I didn't think of this earlier! On 13 June 2010 18:39, doug livesey <[email protected]> wrote: > It was in a reply from David Chelimsky, although it looks like he may have > changed his mind on the issue, as the link in the reply no longer works: > > <EMAIL> > On Mon, Apr 27, 2009 at 3:09 PM, doug livesey <[email protected]> wrote: > > Hi -- I'm assuming that there are excellent reasons for not enabling > stubs & > > mocks in cucumber, but I find myself in a bit of a pickle without them. > > Aslak and I were discussing this very thing earlier today. There are > definitely good reasons not to use message expectations (mocks - see > http://wiki.github.com/aslakhellesoy/cucumber/mocking-with-cucumber) > in cucumber, but stubs are different and we're thinking there should > be support for them. > </EMAIL> > > -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
