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]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
