[rspec-users] I need some guidance
pergesu at gmail.com
Fri Dec 21 13:56:13 EST 2007
On Dec 21, 2007 10:30 AM, jimmy zimmerman <jimmy.zimmerman at gmail.com> wrote:
> I'm building an http communicator class for a web service API wrapper and
> I'm trying to go through the BDD process in doing so. I'm having a bit of a
> struggle figuring out how to set up the tests in relation to isolating
> things appropriately as well as testing behavior vs testing implementation.
> Specifically, I'm trying to set up a post method on my HttpCommunicator so I
> have the following:
> describe FamilyTreeApi::HttpCommunicator, "post" do
> it "should accept an endpoint and an xml string to post" # I'm okay with
> this one
> it "should perform post content to given endpoint"
> it "should return a response object"
> I have written/passed the tests for the first spec, but I'm having troubles
> figuring out how to verify behavior for the second and third, and how to
> mock/stub it up. I'll be using the 'net/https' standard libraries to
> implement the POST action, and I know that it requires the use of a URI
> instance, a Net::HTTP instance, and a Net::HTTP::Post request instance.
> I don't want to hit the actual web service each time I run the test, so I'd
> like to stub or mock this in some way. I think I just need some guidance on
> how to approach something like this.
> Do I just ignore the implementation details?
> Do I push the actual posting of data to a private method and mock that
> method so that I can verify that it is being called?
> Would you recommend I actually hit the web service?
> Any help is greatly appreciated.
> Jimmy Zimmerman
> rspec-users mailing list
> rspec-users at rubyforge.org
There's a PeepCode screencast where he shows how to do something like
this I think...in the past, I've always used mocks to drive an
internal API that I like. Then when that's more or less locked down,
I write a spec to implement that API. I pull response pages from the
external service, and stub Net::HTTP to return those. It's a tad bit
brittle, because if the service changes then your specs will be
invalid. However by writing the client code and driving the API
first, you can at least guarantee that you keep a clean API that you
want, that remains decoupled from the external service.
More information about the rspec-users