Testing an API I'm creating, need test server to be running


#1

Hi,

As I am writing a brand new API, I’d like to test it’s response.

Obviously, controller tests are great and work like a charm but as I
expose data which are not really resources, I’ve to make some DIY to
provide responses that ActiveResource can handle properly.

Basically, it would be great in my case to test if ActiveResource gets
the expected data but it means I have to launch a test server in
background for the whole suite.

Is there a convenient to handle this? Currently, I launch the test
server in console but it would be much better to have this handled
programmatically.

Thanks in advance,

Ben


#2

On Jan 14, 2012, at 8:40 AM, apneadiving wrote:

As I am writing a brand new API, I’d like to test it’s response.

Basically, it would be great in my case to test if ActiveResource gets
the expected data but it means I have to launch a test server in
background for the whole suite.

Is there a convenient to handle this? Currently, I launch the test
server in console but it would be much better to have this handled
programmatically.

I’d recommend you check out https://github.com/brynary/rack-test. It
provides access to attributes of the request and the response object,
and obviates the need for running a server. Take a look at its specs:
https://github.com/brynary/rack-test/blob/master/spec/rack/test_spec.rb.

HTH,
David


#3

On Jan 14, 2012, at 10:32 AM, David C. wrote:

programmatically.

I’d recommend you check out https://github.com/brynary/rack-test. It provides
access to attributes of the request and the response object, and obviates the need
for running a server. Take a look at its specs:
https://github.com/brynary/rack-test/blob/master/spec/rack/test_spec.rb.

Of course, you get rack-test for free if you use request specs (which
wrap Rails integration tests, which use rack-test).

http://rubydoc.info/gems/rspec-rails/file/README.md#Request_Specs
http://guides.rubyonrails.org/testing.html#integration-testing


#4

Agreed. This is even more a bullet to bite early if your app
orchestrates
over more than one service, or if services talk to other services or
both.

Testing this kind of setup is pretty difficult and the tests are
typically
very brittle.

Best,
Sidu.
http://c42.in
http://rubymonk.com

Sent from my phone


#5

On Sun, Jan 15, 2012 at 3:36 AM, David C. removed_email_address@domain.invalid
wrote:

the expected data but it means I have to launch a test server in
It provides access to attributes of the request and the response object, and
obviates the need for running a server. Take a look at its
specs: https://github.com/brynary/rack-test/blob/master/spec/rack/test_spec.rb.

Of course, you get rack-test for free if you use request specs (which wrap
Rails integration tests, which use rack-test).

This could be considered to be off topic, but rack-test was advised…

Some think this issue is a trap for young players, others that it is
just a different test philosophy. Nonetheless:

After a while you will eventually face the fact that you have to
test responses from your whole ‘stack’, specifically all the
interactions of the different components, and rack-test does not do
this.
Better to bite this bullet early.
FWIW I have unit tests that are just that, and integration tests that
are, well, integration tests - which precludes (by definition) using
rack-test :slight_smile:
To get interagtion tests running (quickly) you’ll likely need to use
Vagrant+Chef+VCR, or some such toolbox, to launch your test stack
(locally, AWS, Rackspace etc.)

Again, this is inevitable, so better to bite integration testing early
while things are simple - build the complexity incrementally over
time.

From someone who years ago wasted too many days trying to isolate
issues that rack-test happily passed.

Now at least you can’t say your weren’t forewarned :wink:

HTH

http://rubyforge.org/mailman/listinfo/rspec-users

πόλλ’ οἶδ ἀλώπηξ, ἀλλ’ ἐχῖνος ἓν μέγα
[The fox knows many things, but the hedgehog knows one big thing.]
Archilochus, Greek poet (c. 680 BC – c. 645 BC)
http://hedgehogshiatus.com


#6

How one should test an API which depends on other web services (SOAP
etc). e.g. Login to my API internally calls to another webservice API
for authentication. Also all the data sent back by my API is actually
data retrieved from another web service. Also should we verify the data
or just responses are 200 or something else.

Any thoughts?

Sidu P. wrote in post #1040936:

Agreed. This is even more a bullet to bite early if your app
orchestrates
over more than one service, or if services talk to other services or
both.

Testing this kind of setup is pretty difficult and the tests are
typically
very brittle.

Best,
Sidu.
http://c42.in
http://rubymonk.com

Sent from my phone


#7

Thanks for all your answers,

I should have said I’m very used to the workflow of integration specs
and capybara.

My question is really oriented towards API testing and particularly on
the use of Active Resource.

Basically, I’d like to:
a- create ActiveResource classes in rspec/support
b- run my tests

for a, I don’t really know what URL I should provide
for b, according to what you said, this kind of tests should live in
rspec/requests

Any more enlightenment? :slight_smile:

Ben


#8

For mocking other web services based on REST (ActiveResource) I use Dupe
gem.
(https://github.com/moonmaster9000/dupe).
It is similar to FactoryGirl.