--0015175cb26e3fde650461300cec
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Check out fakeweb which can be used to help mock out your web service calls
easily:
http://technicalpickles.com/posts/stop-net-http-dead-in-its-tracks-with-fakeweb

Matt



On Fri, Jan 23, 2009 at 2:13 PM, Phlip <phlip2005 / gmail.com> wrote:

> Brent Collier wrote:
>
>> When testing code that consumes a web service, is it bad for the
>> tests/specs to actually hit the api, or should the get/post/whatever
>> requests be stubbed out?
>>
>
> Two reasons it's bad. The first is a simple rule "never hit the wire at
> test time". It annoys the remote server, and exposes your test runs to false
> negatives if that server is down (or when it finally blacklists your
> development workstation!).
>
> The other rule is Mike Feathers's guideline for testing: "Test cases should
> never touch the file system, the database, or the wires." That's not a rule,
> it's just a head-game to encourage his disciples to decouple their code and
> improve its isolation and encapsulation. Intermediate logic code should not
> have runaway dependencies on low-level code with side-effects.
>
>  I'm currently writing a Ruby gem for a particular micro-blogging api. My
>> tests actually make requests against the api and I was just wondering if
>> maybe I shouldn't be doing that...
>>
>
> Run those tests one last time, with p statements that barf out the
> low-level responses as strings.
>
> Use Mocha to mock the HTTP::Post activity (or whatever), and copy those
> tests into the .returns(). Then run your tests with your network wire
> unplugged (yes, and take a long uneasy break from twitter, boingboing, apod,
> chat, google, RSS, and this newsgroup!), and make sure all your tests still
> pass.
>
> --
>  Phlip
>
>


-- 
Matt Todd
Highgroove Studios
www.highgroove.com
cell: 404-314-2612
blog: maraby.org

Scout - Web Monitoring and Reporting Software
www.scoutapp.com

--0015175cb26e3fde650461300cec--