Proposal: Fake it till you make it

[Richard Livsey]

I've written a few things recently which work against 3rd party HTTP
API's recently.

In doing so I always run across the issue of how to spec these
interactions, how to debug what's being passed back and forth etc...

In my rspreedly gem [1] I stub out the HTTP requests on a fairly low
level and use fixtures for the XML being passed which I generated by
using Martin's net-http-spy [2].

Other options include:

 * FakeWeb [3]
 * Just use the actual service
 * Build a mock/simulated app to test against
 * A replaying middleman/proxy like wiretapper [4]

Would anyone be interested in a talk where I look into these
issues/options and the pros and cons of the various approaches?

[1] http://github.com/rlivsey/rspreedly
[2] http://github.com/martinbtt/net-http-spy/
[3] http://fakeweb.rubyforge.org/
[4] http://github.com/joshuabates/wiretapper/

--
Richard Livsey
Minutebase - Online Meeting Minutes
http://minutebase.com
http://livsey.org

[Matt Patterson]

On 17 Nov 2009, at 15:11, Richard Livsey wrote:

> I've written a few things recently which work against 3rd party HTTP
> API's recently.
>
> In doing so I always run across the issue of how to spec these
> interactions, how to debug what's being passed back and forth etc...
>
> In my rspreedly gem [1] I stub out the HTTP requests on a fairly low
> level and use fixtures for the XML being passed which I generated by
> using Martin's net-http-spy [2].
>
> Other options include:
>
> * FakeWeb [3]
> * Just use the actual service
> * Build a mock/simulated app to test against
> * A replaying middleman/proxy like wiretapper [4]
>
> Would anyone be interested in a talk where I look into these
> issues/options and the pros and cons of the various approaches?

+1 from me. I've used FakeWeb extensively, and run into some interesting issues - would like to see the terrain surveyed...

Matt

--
Matt Patterson | Design & Code
<ma...@reprocessed.org> | http://www.reprocessed.org/

[James Adam]

I think this might be most interesting to me with a walk-through example; I know about FakeWeb, or at least that it exists, but I don't tend to reach for it. Maybe if I see how someone builds their tests against in with some concrete examples.

What do you think?

- James

[Richard Livsey]

I've not used FakeWeb myself, so figure it might be a good time to look into it!

I was thinking of maybe going through each of the options, showing
some real examples of how specs could work for each one and then a bit
of compare and contrast to see the benefits of each method?

[Martin Sadler]

+1
I think there is a lot of good discussion to be had around this
and I'd also be interested in hearing thoughts on the different
techniques.
My gem is just one tool in the box for this kind of stuff

On 17 Nov 2009, at 15:11, Richard Livsey wrote:

>

> --~--~---------~--~----~------------~-------~--~----~
> http://rubymanor.org
> Group home: http://groups.google.com/group/ruby-manor?hl=en
> Unsubscribe at ruby-manor+...@googlegroups.com
> -~----------~----~----~----~------~----~------~--~---
>

[Kerry Buckley]

On Tue, Nov 17, 2009 at 3:11 PM, Richard Livsey <liv...@gmail.com> wrote:
>
> I've written a few things recently which work against 3rd party HTTP
> API's recently.
>
> In doing so I always run across the issue of how to spec these
> interactions, how to debug what's being passed back and forth etc...
>
> In my rspreedly gem [1] I stub out the HTTP requests on a fairly low
> level and use fixtures for the XML being passed which I generated by
> using Martin's net-http-spy [2].
>
> Other options include:
>
>  * FakeWeb [3]
>  * Just use the actual service
>  * Build a mock/simulated app to test against
>  * A replaying middleman/proxy like wiretapper [4]

I cobbled together FakeTTP (http://github.com/kerryb/fakettp), which
is aimed more at integration testing. It works as a generic stub/mock
web server, so relies on you either being able to configure the app to
talk to a different host, or overriding the DNS in your hosts file.

Kerry

[alan]

I am up for this. It be good to hear of things to watch out when using
this approach, ie at what level of testing it works best, and when is
better to test it against the real 3rd party. Examples would be great
also.

Alan

[Bartosz Blimke]

I was also struggling with stubbing HTTP requests in one of the
projects and I created
recently WebMock (http://github.com/bblimke/webmock).
I was thinking about giving a lightning talk at Ruby Manor.

Here are some features:

* Stubbing requests and verifying expectations of request executions
* Matching requests based on method, url, headers and body
* Support for Test::Unit and RSpec (and can be easily extended to
other frameworks)
* Support for Net::Http and other http libraries based on Net::Http
* Adding other http library adapters is easy

Bartosz

[Roland Swingler]

This sounds cool. I've used FakeWeb a bit, and like it, but it is a
bit limited (can't cope with POST requests and doesn't normalize
parameters/escaping). If WebMock can cope with those it would be
interesting to hear about.

Cheers,
Roland

> --

[Bartosz Blimke]

Hi Roland,

WebMock works fine with POST requests. You can stub requests and set execution expectations,

based on request body and headers in addition to url and http method.
Since new version 0.7.2 it also matches escaped vs not escaped urls.

Cheers,

Bartosz

2009/11/20 Roland Swingler <roland....@gmail.com>

[Richard Livsey]

We've just moved over to WebMock at work now and it's going well!

I'm happy to step aside and let Bartosz give a talk on that?

Or alternatively maybe I do a short talk on why/when to stub requests
vs testing against live data and then hand over to Bartosz to cover
WebMock?

[Kalvir Sandhu]

I'm looking forward to hearing about WebMock and these other techniques in testing API services.

I have used Fakeweb for most services but I had issues when an underlying library didn't use net::http. So I would be interested to know how best to test code or libraries that don't use the expected net::http.

At the time I created my own rack server to mock responses for feedzirra (http://github.com/pauldix/feedzirra), which uses Curb in the guts of it. Would love to hear your views on this, whether to bother even, just switch or write something that uses net::http.

Kalv