Best way to test web services and XMLHttpRequest

Hello.

How do you test your web services and XHR requests?

Like many of us I have render :xml => @obj in my controllers. I also
have something like render :json => @obj if xhr? in my controller. I
also use some custom XML serialization in my models by overriding
to_json and as_json.

How do you test that all? I test the custom serialization in my model.
But ask myself where to test the other stuff. In the controller tests?
There I can stub a model, use the get or xhr method for example
and evaluate the returned response.body. Or should I test that as an
integration test? The problem is that with Capybara (using it with
Steak) I can’t do post or xhr requests (Capybara is get only).

Best regards,
Kai

turkan wrote in post #961926:

Hello.

How do you test your web services and XHR requests?

Like many of us I have render :xml => @obj in my controllers. I also
have something like render :json => @obj if xhr? in my controller. I
also use some custom XML serialization in my models by overriding
to_json and as_json.

How do you test that all? I test the custom serialization in my model.
But ask myself where to test the other stuff.

In your Cucumber stories, of course!

In the controller tests?
There I can stub a model, use the get or xhr method for example
and evaluate the returned response.body. Or should I test that as an
integration test? The problem is that with Capybara (using it with
Steak) I can’t do post or xhr requests (Capybara is get only).

Controller and integration tests are needlessly painful. Skip them.
Use Cucumber.

Best regards,
Kai

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

In your Cucumber stories, of course!

But even in Cucumber you have to implement that somehow, or?
I don’t know much about Cucumber as I do use Steak as mentioned, but I
am pretty sure that there is a way to do that there, too.

Controller and integration tests are needlessly painful. Skip them.
Use Cucumber.

So you don’t test your controllers at all? What do you mean by
integration test are painful. What are Cucumber tests then?

turkan wrote in post #961947:

In your Cucumber stories, of course!

But even in Cucumber you have to implement that somehow, or?

Right.

I don’t know much about Cucumber as I do use Steak as mentioned, but I
am pretty sure that there is a way to do that there, too.

I hadn’t heard of Steak before. A quick look at the rdoc makes me think
it’s basically an inferior version of Cucumber. :slight_smile: It looks to me like
the author of Steak kind of missed the point that the English-like
syntax of Cucumber is usually an advantage.

Controller and integration tests are needlessly painful. Skip them.
Use Cucumber.

So you don’t test your controllers at all?

I do test them, but only by means of my Cucumber stories. There’s no
reason to write conventional tests for controllers.

What do you mean by
integration test are painful.

The integration testing interface provided by Test::Unit and RSpec is
difficult to use and brittle. You couldn’t pay me enough to touch it.

What are Cucumber tests then?

A non-painful way to cover the same ground as integration tests.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

I hadn’t heard of Steak before. A quick look at the rdoc makes me think
it’s basically an inferior version of Cucumber. :slight_smile: It looks to me like
the author of Steak kind of missed the point that the English-like
syntax of Cucumber is usually an advantage.

Usually is not always. And not in our case.

What are Cucumber tests then?

A non-painful way to cover the same ground as integration tests.

In my opinion (and by definition too :wink: are Cucumber tests
integration tests, or at least acceptance tests.

But back to the topic … do you have a little example how you would
test an XHR request that responds with some JSON data by using
Cucumber?
A guess you are using Capybara too. How do you do the XHR request?

In what way not? I suspect that if you can’t write your Cucumber
stories in English, you’re putting too much into them that should be in
model specs…

In some cases developers choose to simply not want the verbosity of
Cucumber.
Belief it or not :stuck_out_tongue: It is the same discussion like erb vs haml.

I would just make a request to the appropriate URL, and then test the
returned JSON. Just like testing HTML. There’s no reason to complicate
it further.

Ok, the main problem here seems by investigating a bit further that
you Cucumber guys have access to the
ActionDispatch::Integration::RequestHelpers
methods, like xhr and post. But it is not included in with Steak, and
I don’t know how to get it working there. I will refine my question
and start a new thread.

turkan wrote in post #961975:

I hadn’t heard of Steak before. A quick look at the rdoc makes me think
it’s basically an inferior version of Cucumber. :slight_smile: It looks to me like
the author of Steak kind of missed the point that the English-like
syntax of Cucumber is usually an advantage.

Usually is not always. And not in our case.

In what way not? I suspect that if you can’t write your Cucumber
stories in English, you’re putting too much into them that should be in
model specs…

What are Cucumber tests then?

A non-painful way to cover the same ground as integration tests.

In my opinion (and by definition too :wink: are Cucumber tests
integration tests, or at least acceptance tests.

Yes, they serve that purpose. They’re not what Rails developers usually
think of by hose terms, though. Sorry for the confusion.

But back to the topic … do you have a little example how you would
test an XHR request that responds with some JSON data by using
Cucumber?
A guess you are using Capybara too. How do you do the XHR request?

I’m not using Capybara; I’m using Webrat.

I would just make a request to the appropriate URL, and then test the
returned JSON. Just like testing HTML. There’s no reason to complicate
it further.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

On Nov 17, 3:09am, Marnen Laibow-Koser [email protected] wrote:

turkan wrote in post #962004:
Then that tells me that their stories are too verbose.

English language is verbose :wink:

No, it really isn’t. ERb is not going to camouflage poorly designed
views. Steak looks very much like that’s its primary design goal:
making it easier to write excessively intrusive stories.

I would be very curious to see some sample Steak tests.

Steak is a very very thin wrapper around RSpec … so the test are
nearly pure Ruby/RSpec (mostly by directly accessing the Capybara
Api).
Example (not from me):
https://github.com/jaimeiniesta/demo_steak_capybara/blob/master/spec/acceptance/article_management_spec.rb

Doesn’t Capybara do all that regardless?

Nope, from the Capybara README.rdoc: “The visit method only takes a
single parameter, the request method is always GET.”

turkan wrote in post #962004:

In what way not? I suspect that if you can’t write your Cucumber
stories in English, you’re putting too much into them that should be in
model specs…

In some cases developers choose to simply not want the verbosity of
Cucumber.
Belief it or not :stuck_out_tongue:

Then that tells me that their stories are too verbose.

It is the same discussion like erb vs haml.

No, it really isn’t. ERb is not going to camouflage poorly designed
views. Steak looks very much like that’s its primary design goal:
making it easier to write excessively intrusive stories.

I would be very curious to see some sample Steak tests.

I would just make a request to the appropriate URL, and then test the
returned JSON. Just like testing HTML. There’s no reason to complicate
it further.

Ok, the main problem here seems by investigating a bit further that
you Cucumber guys have access to the
ActionDispatch::Integration::RequestHelpers
methods, like xhr and post. But it is not included in with Steak, and
I don’t know how to get it working there. I will refine my question
and start a new thread.

Doesn’t Capybara do all that regardless?

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

I have been using the ruby rest-client to test the webservice
integration: see GitHub - archiloque/rest-client: A link to the new repository in
conjunction with cucumber and rspec. Admittedly in a Sinatra
environment but it will work with Rails too. That and Xpath
http://ruby-doc.org/stdlib/libdoc/rexml/rdoc/classes/REXML/XPath.html
should work for you.

O.

turkan wrote in post #962094:

On Nov 17, 3:09am, Marnen Laibow-Koser [email protected] wrote:

turkan wrote in post #962004:
Then that tells me that their stories are too verbose.

English language is verbose :wink:

You’re right. I used the wrong word. That tells me that their stories
are too complex.

No, it really isn’t. ERb is not going to camouflage poorly designed
views. Steak looks very much like that’s its primary design goal:
making it easier to write excessively intrusive stories.

I would be very curious to see some sample Steak tests.

Steak is a very very thin wrapper around RSpec … so the test are
nearly pure Ruby/RSpec (mostly by directly accessing the Capybara
Api).
Example (not from me):

https://github.com/jaimeiniesta/demo_steak_capybara/blob/master/spec/acceptance/article_management_spec.rb

Interesting. I like parts of it, but I think Steak is fundamentally
misconceived.

One of the big reasons to write Cucumber stories in natural language is
that it stops you thinking like a programmer – Cucumber stories are
about user-facing functionality, not implementation. Steak, with its
Ruby syntax, completely destroys that difference. Its Ruby DSL is
clever, but there appears to be a great temptation to write RSpec
controller specs with nicer syntax – which is really not what user
stories are about.

Have you actually used Cucumber?

Doesn’t Capybara do all that regardless?

Nope, from the Capybara README.rdoc: “The visit method only takes a
single parameter, the request method is always GET.”

GET is all you need. If you want POST, you should be having the
Capybara robot submit the form by clicking on the button.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone