> If so you may want to isolate the decision, eg define SALESFORCE_SERVICE_CLASS or whatever somewhere. Yeah, you're right. The method was so that I could transparently alter the class in the cuke setup, but explicitly using a constant would be better.
> You're actually doing a hybrid there, being able to set (or at least verify) expectations, AND running the actual code. Why do you need to do both? The reason is that to use WebMock to check that what I wanted to happen had happened was a complete PITA -- I was running into all sorts of horrible URL encoding issues that were eating my time, so decided that it would be best to just confirm against an version of the class that just recorded methods and signatures. I already had the correct values returning due to stubbing with WebMock in my factory_girl factories file, so I guess I allowed myself to just isolate the bit that was causing me the difficulty. Hmm. When I get chance to revisit the code, I think I'll have to choose one strategy or the other, as the current setup is far from intuitive. Just when you think you've put something to bed ... :) Actually, and in all seriousness, conversations like this really hit home how potentially devastatingly effective pair-programming could be. Does anyone on the list work that way? On 27 June 2010 20:25, Ashley Moran <[email protected]> wrote: > > On 17 Jun 2010, at 5:36 AM, doug livesey wrote: > > > 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, > > Hi Doug > > What you're doing here is a form of dependency injection, but possibly a > slightly opaque one. How are you replacing the Salesforce::Service method? > If it's by stubbing, you may find that this pattern leads to a lot of "what > code actually gets run here?" questions. If so you may want to isolate the > decision, eg define SALESFORCE_SERVICE_CLASS or whatever somewhere. > > > > 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! > > You're actually doing a hybrid there, being able to set (or at least > verify) expectations, AND running the actual code. Why do you need to do > both? What does one tell you in this situation that the other doesn't? > > > Ash > > > -- > http://www.patchspace.co.uk/ > http://www.linkedin.com/in/ashleymoran > > > > -- > 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]<nwrug-members%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nwrug-members?hl=en. > > -- 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.
