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>
