X-BeenThere: webmock-users@googlegroups.com
Received: by 10.213.3.206 with SMTP id 14ls745632ebo.0.p; Wed, 20 Jan 2010
01:50:13 -0800 (PST)
Received: by 10.213.27.1 with SMTP id g1mr1056690ebc.9.1263981012893;
Wed, 20 Jan 2010 01:50:12 -0800 (PST)
Received: by 10.213.27.1 with SMTP id g1mr1056687ebc.9.1263981012692;
Wed, 20 Jan 2010 01:50:12 -0800 (PST)
Return-Path: <bartosz.bli...@gmail.com>
Received: from mail-ew0-f220.google.com (mail-ew0-f220.google.com [209.85.219.220])
by gmr-mx.google.com with ESMTP id 18si422661ewy.0.2010.01.20.01.50.11;
Wed, 20 Jan 2010 01:50:11 -0800 (PST)
Received-SPF: pass (google.com: domain of bartosz.bli...@gmail.com designates 209.85.219.220 as permitted sender) client-ip=209.85.219.220;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of bartosz.bli...@gmail.com designates 209.85.219.220 as permitted sender) smtp.mail=bartosz.bli...@gmail.com; dkim=pass (test mode) header...@gmail.com
Received: by mail-ew0-f220.google.com with SMTP id 20so3587549ewy.20
for <webmock-users@googlegroups.com>; Wed, 20 Jan 2010 01:50:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:in-reply-to:references
:date:message-id:subject:from:to:content-type;
bh=pA+IT1UgJ4T47+eBZVkrsC9bbrR349krCm+07ri+EQQ=;
b=rloEVrZZ5oDfSawk+yNg7Cm5bERypL0iNjVTteWSMps+1egwdAD1JYs8QSKnB5bq0A
33Lz17twO69+y3W/kvdIjXTj5m3dgp9obPKnpFyQefmzOqqTCV3ka7+jif/ghHjm5DBE
lbazOcc5Uv/mOjBXmmevFEUbFbWM/zU0bFl1Q=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=QYOjsty1KGnra/N+WaL2SyO0vY8TQRTnJ0+0i0YXXzIQEX20o0Herbr2wfRzITEqbu
9R37Zn8pLoWzg29ZW770B1hyyRCYsbVDgWI3iI5D+tEIhhNJVZX5yL4yPrzJnNccXUAM
ZA1l/q3l8/UWjd8TjrouHXQUCx+v3b+VZGt8I=
MIME-Version: 1.0
Received: by 10.213.73.204 with SMTP id r12mr2400255ebj.72.1263981010998; Wed,
20 Jan 2010 01:50:10 -0800 (PST)
In-Reply-To: <c247003c-1ed0-4431-bc48-d8745ce46...@36g2000yqu.googlegroups.com>
References: <9190f26a-c8c0-4ddb-a325-06dafebd2...@c29g2000yqd.googlegroups.com>
<53dc2cd21001180554m5fe2686dya23164d1b6329...@mail.gmail.com>
<6bad3b3f-e048-45ba-8084-193df6903...@36g2000yqu.googlegroups.com>
<53dc2cd21001191527l4000aafauf2d451be41e5a...@mail.gmail.com>
<c247003c-1ed0-4431-bc48-d8745ce46...@36g2000yqu.googlegroups.com>
Date: Wed, 20 Jan 2010 09:50:10 +0000
Message-ID: <53dc2cd21001200150j1b318625jced95f16d3abb...@mail.gmail.com>
Subject: Re: Stubbing multiple responses to the same uri
From: Bartosz Blimke <bartosz.bli...@gmail.com>
To: webmock-users@googlegroups.com
Content-Type: multipart/alternative; boundary=00c09f76ad282a40ca047d9583a2
--00c09f76ad282a40ca047d9583a2
Content-Type: text/plain; charset=ISO-8859-1
I would suspect that rarely anyone would use long chains (but I may be
mistaken). I usually stub requests with a single response, but your specific
case can be different. I do agree that fluent interfaces can significantly
reduce readability if chains are too long.
One thing I don't like, is mixing :times attribute in the response with
other response specific attributs. While :body and :headers are obviously
part of the response model, :times is not.
Another problem is, how to define a stub that first returns response and on
the next request raises exception. It's easy with
to_return(...).then.to_raise(...). I again don't like the idea of mixing
:exception attribute inside response, where it doesn't seem to belong.
Ant thoughts?
Bartosz
2010/1/20 Arvicco <arvitall...@gmail.com>
> Bartosz,
>
> Proposed interface for curl-gathered responses looks good to me,
> indeed in makes sense when you're providing the whole response
> (either from file or from string).
>
> Regarding syntax for multiple responses, I totally understand your
> desire
> to provide fluent interfaces. However it will be much more difficult
> to stub
> multiple responses programmatically with this approach. Instead of
> pushing all the necessary response hashes into array (adding :times
> key as necessary) and then stubbing the whole set of responses in
> one concise sentence, now you'll have to.. do what? construct a mile-
> long
> method chain or "times(n).then.to_return({...}).times(m).then.to_return
> (..." ?
> While improving readability somewhat in case of short response chains
> (2-3 responses) in will become so unwieldy with longer response
> chains... :(
>
> You have noticed another problem with such interface("what should be
> returned
> as the 6th response?") resulting from :times directive not being part
> of response
> hash, but rather a separate member of method chain.
>
> On Jan 20, 2:27 am, Bartosz Blimke <bartosz.bli...@gmail.com> wrote:
> > I'm planning to add multiple responses with the following syntax:
> >
> > stub_request(:any, "www.example.com").to_return({ :body => "abc"}, {
> :body
> > => "def" }).then.to_return({ :body => "ghj" }).then.to_raise(Error)
> >
> > Is "times" functionality useful? If yes, then it could be possibly added
> > with syntax like:
> >
> > stub_request(:any, "www.example.com").to_return({ :body =>
> > "abc"}).times(5).then.to_return({ :body => "ghj" })
> >
> > the only problem is, what should be returned as the 6th response, for the
> > following stub:
> >
> > stub_request(:any, "www.example.com").to_return({ :body => "abc"}, {
> :body
> > => "def" }).times(5).then.to_return({ :body => "ghj" }) ?
> >
> > Replying responses recorded with curl sound like a useful feature. I
> would
> > add support using the following syntax:
> >
> > curl -ihttp://www.example.com/> response_for_www.example.com
> >
> > stub_request(:any, "www.example.com").to_return(File.new("
> > response_for_www.example.com"))
> >
> > and
> >
> > response = File.new("response_for_www.example.com").read
> > stub_request(:any, "www.example.com").to_return(response)
> >
> > Bartosz
> >
> > 2010/1/18 Arvicco <arvitall...@gmail.com>
> >
> > > Thanks for your reply! Yes, this is exactly how it's implemented in
> > > FakeWeb and nobody seems to complain about it. In addition, you can
> > > accept something like :times=>n key in response hash that makes
> > > WebMock return this response exactly n times (again, this is something
> > > FakeWeb does).
> >
> > > Another thing which seems to be missing in WebMock right now, is the
> > > ability to stub whole response from file, not just body (as FakeWeb
> > > does with its :response key). The reason for that, usually you have a
> > > whole set of response stubs collected with "curl -i
> > >http://www.example.com/
> > > > response_for_www.example.com". Now, it would be much easier to use
> > > WebMock as an (almost) drop-in replacement for FakeWeb if you are able
> > > to re-use these stub files. Instead of trying to split them all into
> > > body and headers and manually set headers/status in stub_request, it's
> > > much better to be able to say:
> > > stub_request(:any, "www.example.com").to_return(:response => "/
> > > path/to/your/stub/file")
> >
> > > Other than that, WebMock looks like a really great replacement for
> > > FakeWeb with added functionality (like setting expectations for
> > > request body and query params that's not possible currently with
> > > fakeweb_matcher).
> >
> > > On Jan 18, 4:54 pm, Bartosz Blimke <bartosz.bli...@gmail.com> wrote:
> > > > Hi,
> >
> > > > There is no way to stub identical request to respond with a sequence
> of
> > > > responses in WebMock currently.
> >
> > > > This could be easily implemented i.e. by passing an array of response
> > > hashes
> > > > to the to_return() method.
> > > > The only problem is - how should WebMock behave after the last
> response
> > > was
> > > > returned?
> > > > Would it be ok if it returned the last response from a sequence
> > > infinitely?
> >
> > > > Let me know if you have any thought.
> >
> > > > Bartosz
> >
> > > > 2010/1/18 Arvicco <arvitall...@gmail.com>
> >
> > > > > Is there a way to stub several responses in sequence (say, first
> post
> > > > > to ***/delete returns delete token, second post returns status). In
> > > > > FakeWeb, you can do it by registering an array of responses to
> > > > > specific uri.
> >
> > > > > What is the WebMock way of doing it? If it is even possible, of
> course
> > > > > - since your Readme states: "Always the last declared stub matching
> > > > > the request will be applied"...
>
--00c09f76ad282a40ca047d9583a2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I would suspect that rarely anyone would use long chains (but I may be mist=
aken). I usually stub requests with a single response, but your specific ca=
se can be different. I do agree that fluent interfaces can significantly re=
duce readability if chains are too long.=A0<div>
One thing I don't like, is mixing :times attribute in the response with=
other response specific attributs. While :body and :headers are obviously =
part of the response model, :times is not.</div><div><br></div><div>Another=
problem is, how to define a stub that first returns response and on the ne=
xt request raises exception. It's easy with to_return(...).then.to_rais=
e(...). I again don't like the idea of mixing :exception attribute insi=
de response, where it doesn't seem to belong.</div>
<div><br></div><div>Ant thoughts?</div><div><br></div><div>Bartosz<br><br><=
div class=3D"gmail_quote">2010/1/20 Arvicco <span dir=3D"ltr"><<a href=
=3D"mailto:arvitall...@gmail.com">arvitall...@gmail.com</a>></span><br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
#ccc solid;padding-left:1ex;">
Bartosz,<br>
<br>
Proposed interface for curl-gathered responses looks good to me,<br>
indeed in makes sense when you're providing the whole response<br>
(either from file or from string).<br>
<br>
Regarding syntax for multiple responses, I totally understand your<br>
desire<br>
to provide fluent interfaces. However it will be much more difficult<br>
to stub<br>
multiple responses programmatically with this approach. Instead of<br>
pushing all the necessary response hashes into array (adding :times<br>
key as necessary) and then stubbing the whole set of responses in<br>
one concise sentence, now you'll have to.. do what? construct a mile-<b=
r>
long<br>
method chain or "times(n).then.to_return({...}).times(m).then.to_retur=
n<br>
(..." ?<br>
While improving readability somewhat in case of short response chains<br>
(2-3 responses) in will become so unwieldy with longer response<br>
chains... :(<br>
<br>
You have noticed another problem with such interface("what should be<b=
r>
returned<br>
as the 6th response?") resulting from :times directive not being part<=
br>
of response<br>
hash, but rather a separate member of method chain.<br>
<div class=3D"im"><br>
On Jan 20, 2:27=A0am, Bartosz Blimke <<a href=3D"mailto:bartosz.bli...@g=
mail.com">bartosz.bli...@gmail.com</a>> wrote:<br>
> I'm planning to add multiple responses with the following syntax:<=
br>
><br>
> =A0stub_request(:any, "<a href=3D"http://www.example.com" target=
=3D"_blank">www.example.com</a>").to_return({ :body =3D> "abc&=
quot;}, { :body<br>
> =3D> "def" }).then.to_return({ :body =3D> "ghj&qu=
ot; }).then.to_raise(Error)<br>
><br>
> Is "times" functionality useful? If yes, then it could be po=
ssibly added<br>
> with syntax like:<br>
><br>
> stub_request(:any, "<a href=3D"http://www.example.com" target=3D"=
_blank">www.example.com</a>").to_return({ :body =3D><br>
> "abc"}).times(5).then.to_return({ :body =3D> "ghj&qu=
ot; })<br>
><br>
> the only problem is, what should be returned as the 6th response, for =
the<br>
> following stub:<br>
><br>
> =A0stub_request(:any, "<a href=3D"http://www.example.com" target=
=3D"_blank">www.example.com</a>").to_return({ :body =3D> "abc&=
quot;}, { :body<br>
> =3D> "def" }).times(5).then.to_return({ :body =3D> &qu=
ot;ghj" }) ?<br>
><br>
> Replying responses recorded with curl sound like a useful feature. I w=
ould<br>
> add support using the following syntax:<br>
><br>
</div>> curl -ihttp://<a href=3D"http://www.example.com/" target=3D"_bla=
nk">www.example.com/</a>> <a href=3D"http://response_for_www.example.com=
" target=3D"_blank">response_for_www.example.com</a><br>
<div class=3D"im">><br>
> stub_request(:any, "<a href=3D"http://www.example.com" target=3D"=
_blank">www.example.com</a>").to_return(File.new("<br>
> <a href=3D"http://response_for_www.example.com" target=3D"_blank">resp=
onse_for_www.example.com</a>"))<br>
><br>
> and<br>
><br>
> response =3D File.new("<a href=3D"http://response_for_www.example=
.com" target=3D"_blank">response_for_www.example.com</a>").read<br>
> stub_request(:any, "<a href=3D"http://www.example.com" target=3D"=
_blank">www.example.com</a>").to_return(response)<br>
><br>
> Bartosz<br>
><br>
</div>> 2010/1/18 Arvicco <<a href=3D"mailto:arvitall...@gmail.com">a=
rvitall...@gmail.com</a>><br>
<div><div></div><div class=3D"h5">><br>
> > Thanks for your reply! Yes, this is exactly how it's implemen=
ted in<br>
> > FakeWeb and nobody seems to complain about it. In addition, you c=
an<br>
> > accept something like :times=3D>n key in response hash that ma=
kes<br>
> > WebMock return this response exactly n times (again, this is some=
thing<br>
> > FakeWeb does).<br>
><br>
> > Another thing which seems to be missing in WebMock right now, is =
the<br>
> > ability to stub whole response from file, not just body (as FakeW=
eb<br>
> > does with its :response key). The reason for that, usually you ha=
ve a<br>
> > whole set of response stubs collected with "curl -i<br>
> ><a href=3D"http://www.example.com/" target=3D"_blank">http://www.e=
xample.com/</a><br>
> > > <a href=3D"http://response_for_www.example.com" target=3D"_b=
lank">response_for_www.example.com</a>". Now, it would be much easier =
to use<br>
> > WebMock as an (almost) drop-in replacement for FakeWeb if you are=
able<br>
> > to re-use these stub files. Instead of trying to split them all i=
nto<br>
> > body and headers and manually set headers/status in stub_request,=
it's<br>
> > much better to be able to say:<br>
> > =A0 =A0stub_request(:any, "<a href=3D"http://www.example.com=
" target=3D"_blank">www.example.com</a>").to_return(:response =3D> =
"/<br>
> > path/to/your/stub/file")<br>
><br>
> > Other than that, WebMock looks like a really great replacement fo=
r<br>
> > FakeWeb with added functionality (like setting expectations for<b=
r>
> > request body and query params that's not possible currently w=
ith<br>
> > fakeweb_matcher).<br>
><br>
> > On Jan 18, 4:54 pm, Bartosz Blimke <<a href=3D"mailto:bartosz.=
bli...@gmail.com">bartosz.bli...@gmail.com</a>> wrote:<br>
> > > Hi,<br>
><br>
> > > There is no way to stub identical request to respond with a =
sequence of<br>
> > > responses in WebMock currently.<br>
><br>
> > > This could be easily implemented i.e. by passing an array of=
response<br>
> > hashes<br>
> > > to the to_return() method.<br>
> > > The only problem is - how should WebMock behave after the la=
st response<br>
> > was<br>
> > > returned?<br>
> > > Would it be ok if it returned the last response from a seque=
nce<br>
> > infinitely?<br>
><br>
> > > Let me know if you have any thought.<br>
><br>
> > > Bartosz<br>
><br>
> > > 2010/1/18 Arvicco <<a href=3D"mailto:arvitall...@gmail.co=
m">arvitall...@gmail.com</a>><br>
><br>
> > > > Is there a way to stub several responses in sequence (s=
ay, first post<br>
> > > > to ***/delete returns delete token, second post returns=
status). In<br>
> > > > FakeWeb, you can do it by registering an array of respo=
nses to<br>
> > > > specific uri.<br>
><br>
> > > > What is the WebMock way of doing it? If it is even poss=
ible, of course<br>
> > > > - since your Readme states: "Always the last decla=
red stub matching<br>
> > > > the request will be applied"...<br>
</div></div></blockquote></div><br></div>
--00c09f76ad282a40ca047d9583a2--
Message from discussion Stubbing multiple responses to the same uri
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |