# Mashup question

**URL:** <https://www.ruby-forum.com/t/mashup-question/141463>\
**Category:** Rails\
**Created:** [June 26, 2008, 2:44am UTC](https://www.ruby-forum.com/t/mashup-question/141463 "2008-06-26T02:44:44Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![paradise](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/8e7dd6/32.png) [@paradise](https://www.ruby-forum.com/u/paradise)\
**Post date:** [June 26, 2008, 2:44am UTC](https://www.ruby-forum.com/t/mashup-question/141463/1 "2008-06-26T02:44:44Z")

</div>

I have a question regarding mashup development. I am currently  
developing a google mashup application and am wondering how to test  
its functionality. I am not sure if I can communicate with the google  
calendar and actually input information into the calendar while in  
development mode. Does anyone know how to do this? Do I actually  
need to launch the site in order to test the integrative  
functionality. Thanks, Dave

---

<div class="post-metadata">

**Author:** ![paradise](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/8e7dd6/32.png) [@paradise](https://www.ruby-forum.com/u/paradise)\
**Post date:** [June 26, 2008, 12:31pm UTC](https://www.ruby-forum.com/t/mashup-question/141463/2 "2008-06-26T12:31:43Z")

</div>

Don’t know, if that’s some help to you.  
I developed a site with payment functionality once.  
The payment stuff was done with some simple interface  
which returned html. For development we used the test  
server of the payment provider, but didn’t want to do this  
for the tests.

Since we’re using rspec for testing, it was quite easy to  
fake this:

Basket.stub!  
(:new\_payment\_cluster).with(baskets(:thorsten\_payment)).and\_return(open(File.dirname( **FILE** )

- “/…/fixtures/tdps\_response/new\_payment\_cluster\_success.xml”).read)

This line stubs the new\_payment\_cluster of the basket model (our  
shopping cart)  
Instead of retrieving the xml response from the server and handing it  
back to the calling  
function it’ll now use a local xml file.

Another use case:

[‘paid’, ‘closed\_success’].each do |partial\_payment\_state|  
response\_xml = ERB.new(open(File.dirname( **FILE** ) + “/…/fixtures/  
tdps\_response/new\_partial\_payment.erb.xml”).read).result(binding)  
Basket.stub!  
(:start\_partial\_payment).with(baskets(:thorsten\_payment)).and\_return(response\_xml)

This takes a xml erb file and replaces parts of it with erb. So I was  
able to use a single xml file to fake several possible responses and  
test against the start\_partial\_payment method to see if the system  
works with those response types (which could be a success or some  
error codes.

So the general idea for rspec is to stub all the methods that  
communicate  
with the outer world and use some local fixture data as response. Not  
necessarily a xml file as used here, this could be simple strings or  
some  
other methods you provide