Fixed this for paperclip with s3 by adapting some of thoughtbot's shoulda macros for paperclip & s3 (that use, in turn, the excellent fakeweb) to my needs. It's pretty horrible catch-as-catch-can coding, so I'll not post any of it, but if anyone ever asks, I'll swallow my pride & stick it in a gist, for what limited sense it may make. Although they'd be better looking at the thoughtbot stuff: http://github.com/thoughtbot/paperclip/blob/master/shoulda_macros/paperclip.rb <http://github.com/thoughtbot/paperclip/blob/master/shoulda_macros/paperclip.rb>Thanks everyone for their advice, and thanks again for an experienced BDD perspective, Ashley! :) Cheers, Doug.
On 21 March 2010 21:01, doug livesey <[email protected]> wrote: > ... And Postmark looks seriously interesting, too, cheers! :) > > > On 21 March 2010 20:58, doug livesey <[email protected]> wrote: > >> Interesting, cheers Ashley -- think I might have a play with that, cheers. >> Doug. >> >> >> On 21 March 2010 09:57, Ashley Moran <[email protected]>wrote: >> >>> >>> On Mar 18, 2010, at 10:38 pm, doug livesey wrote: >>> >>> > Right, so I'm worrying about, at best, fractions of pence sterling for >>> data transfer, which is probably less of a saving than saying "sod it" to >>> the issue & spending dev time on something rather more profitable? >>> >>> Hi Doug >>> >>> The real cost is likely to be not the S3 fees but the time it takes to >>> run your features. Every time you have to fetch off to a remote server adds >>> just a little bit to the run time. Enough of these means you need to wait >>> longer than necessary, which slows down feedback; a lot of these means it >>> might take so long you don't run the features often enough. It depends how >>> many affected scenarios there are, how much S3 slows it down etc etc... >>> >>> What I usually do to get round it is to make the web service a >>> configurable parameter, and write a *tiny* mock service to run locally. >>> Here is an example I wrote with a client to test integration with >>> Postmark[1]: >>> >>> # run very flat apps with merb -I <app file>. >>> >>> Merb::Router.prepare do >>> match("/email/", :method => :get).to(:controller => "postmark", >>> :action => "index") >>> match("/email/", :method => :post).to(:controller => "postmark", >>> :action => "send_email") >>> end >>> >>> class Postmark < Merb::Controller >>> provides :json >>> >>> @@email = nil >>> >>> def index >>> @@email.to_json >>> end >>> >>> def send_email >>> @@email = request.params >>> "" >>> end >>> end >>> >>> You need to write a bit of wrapper code to get the JSON back out, but >>> that gives you a Ruby hash inside Cucumber. It's then really easy to check >>> that the correct parameters got posted. Note that this still has the >>> inherent issue with all mocks: that because we don't own the Postmark API, >>> it could change under us. So we need some process to prevent that breaking >>> our app. Currently the tradeoff is that paying attention for email >>> announcements of API changes is less expensive than the delay incurred by >>> running Cucumber features against a remote API. >>> >>> HTH. This is just what I do in the situations I encounter. As always, >>> YMMV - and it will if your situation is different. >>> >>> Ash >>> >>> >>> [1] http://postmarkapp.com/ >>> >>> >>> -- >>> 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.
