Thanks Pat,<br><br>When I wrote my first message, I think I was missing a big part of the Mock/Stub capabilities. I thought you could only stub or mock methods of a particular instance that had been set up already in the spec. However, I realize now that you can also stub/mock class methods. 
<br><br>I think my approach will be to create a mock object that would give results for method calls that I expect for Net::HTTP. I would then stub the new call on Net::HTTP to return that mock object. I would then set up should_receive verifications on that object to make sure that it&#39;s being called appropriately. That way, I&#39;m not hitting the web service, but I can verify that things are happening correctly in my method. Does this approach sound right?
<br><br>By the way, I have watched the Peepcode screencasts, and they have helped tremendously. I had just missed this (big) part of mocking/stubbing when I watched the Mocks video.<br><br>--<br>Jimmy<br><br><div class="gmail_quote">
On Dec 21, 2007 11:56 AM, Pat Maddox &lt;<a href="mailto:pergesu@gmail.com">pergesu@gmail.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Dec 21, 2007 10:30 AM, jimmy zimmerman &lt;<a href="mailto:jimmy.zimmerman@gmail.com">jimmy.zimmerman@gmail.com</a>&gt; wrote:<br>&gt; I&#39;m building an http communicator class for a web service API wrapper and
<br>&gt; I&#39;m trying to go through the BDD process in doing so. I&#39;m having a bit of a<br>&gt; struggle figuring out how to set up the tests in relation to isolating<br>&gt; things appropriately as well as testing behavior vs testing implementation.
<br>&gt;<br>&gt; Specifically, I&#39;m trying to set up a post method on my HttpCommunicator so I<br>&gt; have the following:<br>&gt;<br>&gt; describe FamilyTreeApi::HttpCommunicator, &quot;post&quot; do<br>&gt; it &quot;should accept an endpoint and an xml string to post&quot; # I&#39;m okay with
<br>&gt; this one<br>&gt; it &quot;should perform post content to given endpoint&quot;<br>&gt; it &quot;should return a response object&quot;<br>&gt; end<br>&gt;<br>&gt; I have written/passed the tests for the first spec, but I&#39;m having troubles
<br>&gt; figuring out how to verify behavior for the second and third, and how to<br>&gt; mock/stub it up. I&#39;ll be using the &#39;net/https&#39; standard libraries to<br>&gt; implement the POST action, and I know that it requires the use of a URI
<br>&gt; instance, a Net::HTTP instance, and a Net::HTTP::Post request instance.<br>&gt;<br>&gt; I don&#39;t want to hit the actual web service each time I run the test, so I&#39;d<br>&gt; like to stub or mock this in some way. I think I just need some guidance on
<br>&gt; how to approach something like this.<br>&gt;<br>&gt; Do I just ignore the implementation details?<br>&gt; Do I push the actual posting of data to a private method and mock that<br>&gt; method so that I can verify that it is being called?
<br>&gt; Would you recommend I actually hit the web service?<br>&gt;<br>&gt; Any help is greatly appreciated.<br>&gt; --<br>&gt; Jimmy Zimmerman<br>&gt; <a href="http://jimmyzimmerman.com/blog/" target="_blank">http://jimmyzimmerman.com/blog/
</a><br></div></div>&gt; _______________________________________________<br>&gt; rspec-users mailing list<br>&gt; <a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br>&gt; <a href="http://rubyforge.org/mailman/listinfo/rspec-users" target="_blank">
http://rubyforge.org/mailman/listinfo/rspec-users</a><br>&gt;<br><br>There&#39;s a PeepCode screencast where he shows how to do something like<br>this I think...in the past, I&#39;ve always used mocks to drive an<br>internal API that I like. &nbsp;Then when that&#39;s more or less locked down,
<br>I write a spec to implement that API. &nbsp;I pull response pages from the<br>external service, and stub Net::HTTP to return those. &nbsp;It&#39;s a tad bit<br>brittle, because if the service changes then your specs will be<br>
invalid. &nbsp;However by writing the client code and driving the API<br>first, you can at least guarantee that you keep a clean API that you<br>want, that remains decoupled from the external service.<br><br>Pat<br>_______________________________________________
<br>rspec-users mailing list<br><a href="mailto:rspec-users@rubyforge.org">rspec-users@rubyforge.org</a><br><a href="http://rubyforge.org/mailman/listinfo/rspec-users" target="_blank">http://rubyforge.org/mailman/listinfo/rspec-users
</a><br></blockquote></div><br><br clear="all"><br>-- <br>Jimmy Zimmerman<br><a href="http://jimmyzimmerman.com">http://jimmyzimmerman.com</a>