Re: Testing against an api
- From: Phlip <phlip2005@xxxxxxxxx>
- Date: Fri, 23 Jan 2009 11:12:43 -0800
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
.
- Follow-Ups:
- Re: Testing against an api
- From: Matt Todd
- Re: Testing against an api
- References:
- Testing against an api
- From: Brent Collier
- Testing against an api
- Prev by Date: Re: [QUIZ] Gathering Ruby Quiz 2 Data (#189)
- Next by Date: Re: How to use two submit tag with form_remote_tag
- Previous by thread: Re: Testing against an api
- Next by thread: Re: Testing against an api
- Index(es):
Relevant Pages
|