Hello Rubyists,
I'm looking for a tool in Ruby which simulates API responses, sometimes
called "data virtualization" or "service virtualization" ... although those
are vague terms of course.
Ideally such a tool would do two things:
* respond immediately to API requests with a stock response simulating what
*would have* been provided had the request been passed to the actual API
provider.
* periodically verify the mock with the API provider, to make sure the
response hasn't become obsolete due to database or other changes.
I'm considering rolling my own, but I thought I would check around a bit.
I'm familiar with VCR in Ruby, GitHub - vcr/vcr: Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests., that's the
closest I can come up with. But just starting my search.
Any suggestions welcome, thank you 
···
--
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
I think you may want to look at https://pact.io/, or building API stubs in
something like https://www.postman.com/
I personally prefer a dependency injection approach so that anything that
can do web requests is swapped in-and-out.
I work in a logistics app that uses VCR a lot, and not being able to load
more than one "cassette" at a time complicates things which need to do both
geocoding, and interacting with some 3rd party API as we can't load both
sets of cassettes (this may be because we integrated VCR poorly, but we
didn't really know we needed this until later, and it hurts us now)
Mocks Aren't Stubs is always worth a
read when talking about mocking and stubbing, etc here's the key table:
- *Dummy* objects are passed around but never actually used. Usually
they are just used to fill parameter lists.
- *Fake* objects actually have working implementations, but usually take
some shortcut which makes them not suitable for production (an in memory
database <InMemoryTestDatabase> is a
good example).
- *Stubs* provide canned answers to calls made during the test, usually
not responding at all to anything outside what's programmed in for the test.
- *Spies* are stubs that also record some information based on how they
were called. One form of this might be an email service that records how
many messages it was sent.
- *Mocks* are what we are talking about here: objects pre-programmed
with expectations which form a specification of the calls they are expected
to receive.
I consider then that VCR fits more in the category of either "fakes" (not
the service you are testing, but you need to use VCR to stop an outgoing
request), or "mocks" (you are verifying something under test using VCR)
On the same topic, I always liked WebMock.disable_net_connect! for
generally raising confidence that I didn't accidentally let some kind of
implicit web request into my app anywhere.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
···
On Wed, 3 Feb 2021 at 04:29, Sean Felipe Wolfe <ether.joe@gmail.com> wrote:
Hello Rubyists,
I'm looking for a tool in Ruby which simulates API responses, sometimes
called "data virtualization" or "service virtualization" ... although those
are vague terms of course.
Ideally such a tool would do two things:
* respond immediately to API requests with a stock response simulating
what *would have* been provided had the request been passed to the
actual API provider.
* periodically verify the mock with the API provider, to make sure the
response hasn't become obsolete due to database or other changes.
I'm considering rolling my own, but I thought I would check around a bit.
I'm familiar with VCR in Ruby, GitHub - vcr/vcr: Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests., that's the
closest I can come up with. But just starting my search.
Any suggestions welcome, thank you
--
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Great information, I'll dig in. Thanks Lee
···
On Wed, Feb 3, 2021 at 11:00 AM Lee Hambley <lee.hambley@gmail.com> wrote:
I think you may want to look at https://pact.io/, or building API stubs
in something like https://www.postman.com/
I personally prefer a dependency injection approach so that anything that
can do web requests is swapped in-and-out.
I work in a logistics app that uses VCR a lot, and not being able to load
more than one "cassette" at a time complicates things which need to do both
geocoding, and interacting with some 3rd party API as we can't load both
sets of cassettes (this may be because we integrated VCR poorly, but we
didn't really know we needed this until later, and it hurts us now)
Mocks Aren't Stubs is always worth a
read when talking about mocking and stubbing, etc here's the key table:
- *Dummy* objects are passed around but never actually used. Usually
they are just used to fill parameter lists.
- *Fake* objects actually have working implementations, but usually
take some shortcut which makes them not suitable for production (an in
memory database
<InMemoryTestDatabase> is a good
example).
- *Stubs* provide canned answers to calls made during the test,
usually not responding at all to anything outside what's programmed in for
the test.
- *Spies* are stubs that also record some information based on how
they were called. One form of this might be an email service that records
how many messages it was sent.
- *Mocks* are what we are talking about here: objects pre-programmed
with expectations which form a specification of the calls they are expected
to receive.
I consider then that VCR fits more in the category of either "fakes" (not
the service you are testing, but you need to use VCR to stop an outgoing
request), or "mocks" (you are verifying something under test using VCR)
On the same topic, I always liked WebMock.disable_net_connect! for
generally raising confidence that I didn't accidentally let some kind of
implicit web request into my app anywhere.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
On Wed, 3 Feb 2021 at 04:29, Sean Felipe Wolfe <ether.joe@gmail.com> > wrote:
Hello Rubyists,
I'm looking for a tool in Ruby which simulates API responses, sometimes
called "data virtualization" or "service virtualization" ... although those
are vague terms of course.
Ideally such a tool would do two things:
* respond immediately to API requests with a stock response simulating
what *would have* been provided had the request been passed to the
actual API provider.
* periodically verify the mock with the API provider, to make sure the
response hasn't become obsolete due to database or other changes.
I'm considering rolling my own, but I thought I would check around a bit.
I'm familiar with VCR in Ruby, GitHub - vcr/vcr: Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests., that's the
closest I can come up with. But just starting my search.
Any suggestions welcome, thank you
--
A musician must make music, an artist must paint, a poet must write, if
he is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
One wild-card too (thanks to the "Rust is 1000× faster than node.js" post
on Reddit yesterday) is this GitHub - opticdev/optic: Optic documents and tests your API as you build it love the
idea, no idea how practical that is to use, seemed quite similar to pact.io
- but anyway is on my list of things to read into.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
···
On Wed, 3 Feb 2021 at 20:06, Sean Felipe Wolfe <ether.joe@gmail.com> wrote:
Great information, I'll dig in. Thanks Lee
On Wed, Feb 3, 2021 at 11:00 AM Lee Hambley <lee.hambley@gmail.com> wrote:
I think you may want to look at https://pact.io/, or building API stubs
in something like https://www.postman.com/
I personally prefer a dependency injection approach so that anything that
can do web requests is swapped in-and-out.
I work in a logistics app that uses VCR a lot, and not being able to load
more than one "cassette" at a time complicates things which need to do both
geocoding, and interacting with some 3rd party API as we can't load both
sets of cassettes (this may be because we integrated VCR poorly, but we
didn't really know we needed this until later, and it hurts us now)
Mocks Aren't Stubs is always worth a
read when talking about mocking and stubbing, etc here's the key table:
- *Dummy* objects are passed around but never actually used. Usually
they are just used to fill parameter lists.
- *Fake* objects actually have working implementations, but usually
take some shortcut which makes them not suitable for production (an in
memory database
<InMemoryTestDatabase> is a good
example).
- *Stubs* provide canned answers to calls made during the test,
usually not responding at all to anything outside what's programmed in for
the test.
- *Spies* are stubs that also record some information based on how
they were called. One form of this might be an email service that records
how many messages it was sent.
- *Mocks* are what we are talking about here: objects pre-programmed
with expectations which form a specification of the calls they are expected
to receive.
I consider then that VCR fits more in the category of either "fakes" (not
the service you are testing, but you need to use VCR to stop an outgoing
request), or "mocks" (you are verifying something under test using VCR)
On the same topic, I always liked WebMock.disable_net_connect! for
generally raising confidence that I didn't accidentally let some kind of
implicit web request into my app anywhere.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
On Wed, 3 Feb 2021 at 04:29, Sean Felipe Wolfe <ether.joe@gmail.com> >> wrote:
Hello Rubyists,
I'm looking for a tool in Ruby which simulates API responses, sometimes
called "data virtualization" or "service virtualization" ... although those
are vague terms of course.
Ideally such a tool would do two things:
* respond immediately to API requests with a stock response simulating
what *would have* been provided had the request been passed to the
actual API provider.
* periodically verify the mock with the API provider, to make sure the
response hasn't become obsolete due to database or other changes.
I'm considering rolling my own, but I thought I would check around a
bit. I'm familiar with VCR in Ruby, GitHub - vcr/vcr: Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests., that's
the closest I can come up with. But just starting my search.
Any suggestions welcome, thank you
--
A musician must make music, an artist must paint, a poet must write, if
he is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
hey Lee, could you pass along a link to that reddit thread if it's
convenient ?
···
On Wed, Feb 3, 2021 at 11:10 AM Lee Hambley <lee.hambley@gmail.com> wrote:
One wild-card too (thanks to the "Rust is 1000× faster than node.js" post
on Reddit yesterday) is this GitHub - opticdev/optic: Optic documents and tests your API as you build it love the
idea, no idea how practical that is to use, seemed quite similar to
pact.io - but anyway is on my list of things to read into.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
On Wed, 3 Feb 2021 at 20:06, Sean Felipe Wolfe <ether.joe@gmail.com> > wrote:
Great information, I'll dig in. Thanks Lee
On Wed, Feb 3, 2021 at 11:00 AM Lee Hambley <lee.hambley@gmail.com> >> wrote:
I think you may want to look at https://pact.io/, or building API stubs
in something like https://www.postman.com/
I personally prefer a dependency injection approach so that anything
that can do web requests is swapped in-and-out.
I work in a logistics app that uses VCR a lot, and not being able to
load more than one "cassette" at a time complicates things which need to do
both geocoding, and interacting with some 3rd party API as we can't load
both sets of cassettes (this may be because we integrated VCR poorly, but
we didn't really know we needed this until later, and it hurts us now)
Mocks Aren't Stubs is always worth
a read when talking about mocking and stubbing, etc here's the key table:
- *Dummy* objects are passed around but never actually used. Usually
they are just used to fill parameter lists.
- *Fake* objects actually have working implementations, but usually
take some shortcut which makes them not suitable for production (an in
memory database
<InMemoryTestDatabase> is a good
example).
- *Stubs* provide canned answers to calls made during the test,
usually not responding at all to anything outside what's programmed in for
the test.
- *Spies* are stubs that also record some information based on how
they were called. One form of this might be an email service that records
how many messages it was sent.
- *Mocks* are what we are talking about here: objects pre-programmed
with expectations which form a specification of the calls they are expected
to receive.
I consider then that VCR fits more in the category of either "fakes"
(not the service you are testing, but you need to use VCR to stop an
outgoing request), or "mocks" (you are verifying something under test using
VCR)
On the same topic, I always liked WebMock.disable_net_connect! for
generally raising confidence that I didn't accidentally let some kind of
implicit web request into my app anywhere.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
On Wed, 3 Feb 2021 at 04:29, Sean Felipe Wolfe <ether.joe@gmail.com> >>> wrote:
Hello Rubyists,
I'm looking for a tool in Ruby which simulates API responses, sometimes
called "data virtualization" or "service virtualization" ... although those
are vague terms of course.
Ideally such a tool would do two things:
* respond immediately to API requests with a stock response simulating
what *would have* been provided had the request been passed to the
actual API provider.
* periodically verify the mock with the API provider, to make sure the
response hasn't become obsolete due to database or other changes.
I'm considering rolling my own, but I thought I would check around a
bit. I'm familiar with VCR in Ruby, GitHub - vcr/vcr: Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests., that's
the closest I can come up with. But just starting my search.
Any suggestions welcome, thank you
--
A musician must make music, an artist must paint, a poet must write, if
he is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
A musician must make music, an artist must paint, a poet must write, if
he is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
···
On Wed, 3 Feb 2021 at 21:20, Sean Felipe Wolfe <ether.joe@gmail.com> wrote:
hey Lee, could you pass along a link to that reddit thread if it's
convenient ?
On Wed, Feb 3, 2021 at 11:10 AM Lee Hambley <lee.hambley@gmail.com> wrote:
One wild-card too (thanks to the "Rust is 1000× faster than node.js" post
on Reddit yesterday) is this GitHub - opticdev/optic: Optic documents and tests your API as you build it love the
idea, no idea how practical that is to use, seemed quite similar to
pact.io - but anyway is on my list of things to read into.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
On Wed, 3 Feb 2021 at 20:06, Sean Felipe Wolfe <ether.joe@gmail.com> >> wrote:
Great information, I'll dig in. Thanks Lee
On Wed, Feb 3, 2021 at 11:00 AM Lee Hambley <lee.hambley@gmail.com> >>> wrote:
I think you may want to look at https://pact.io/, or building API
stubs in something like https://www.postman.com/
I personally prefer a dependency injection approach so that anything
that can do web requests is swapped in-and-out.
I work in a logistics app that uses VCR a lot, and not being able to
load more than one "cassette" at a time complicates things which need to do
both geocoding, and interacting with some 3rd party API as we can't load
both sets of cassettes (this may be because we integrated VCR poorly, but
we didn't really know we needed this until later, and it hurts us now)
Mocks Aren't Stubs is always worth
a read when talking about mocking and stubbing, etc here's the key table:
- *Dummy* objects are passed around but never actually used.
Usually they are just used to fill parameter lists.
- *Fake* objects actually have working implementations, but usually
take some shortcut which makes them not suitable for production (an in
memory database
<InMemoryTestDatabase> is a
good example).
- *Stubs* provide canned answers to calls made during the test,
usually not responding at all to anything outside what's programmed in for
the test.
- *Spies* are stubs that also record some information based on how
they were called. One form of this might be an email service that records
how many messages it was sent.
- *Mocks* are what we are talking about here: objects
pre-programmed with expectations which form a specification of the calls
they are expected to receive.
I consider then that VCR fits more in the category of either "fakes"
(not the service you are testing, but you need to use VCR to stop an
outgoing request), or "mocks" (you are verifying something under test using
VCR)
On the same topic, I always liked WebMock.disable_net_connect! for
generally raising confidence that I didn't accidentally let some kind of
implicit web request into my app anywhere.
Lee Hambley
http://lee.hambley.name/
+49 (0) 170 298 5667
On Wed, 3 Feb 2021 at 04:29, Sean Felipe Wolfe <ether.joe@gmail.com> >>>> wrote:
Hello Rubyists,
I'm looking for a tool in Ruby which simulates API responses,
sometimes called "data virtualization" or "service virtualization" ...
although those are vague terms of course.
Ideally such a tool would do two things:
* respond immediately to API requests with a stock response simulating
what *would have* been provided had the request been passed to the
actual API provider.
* periodically verify the mock with the API provider, to make sure the
response hasn't become obsolete due to database or other changes.
I'm considering rolling my own, but I thought I would check around a
bit. I'm familiar with VCR in Ruby, GitHub - vcr/vcr: Record your test suite's HTTP interactions and replay them during future test runs for fast, deterministic, accurate tests.,
that's the closest I can come up with. But just starting my search.
Any suggestions welcome, thank you
--
A musician must make music, an artist must paint, a poet must write,
if he is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
A musician must make music, an artist must paint, a poet must write, if
he is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org
?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
--
A musician must make music, an artist must paint, a poet must write, if he
is to be ultimately at peace with himself.
- Abraham Maslow
Unsubscribe: <mailto:ruby-talk-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-talk>
