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,

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,

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?

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,

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 #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,

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 #962094:

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,

I have been using the ruby rest-client to test the webservice integration: see https://github.com/archiloque/rest-client in conjunction with cucumber and rspec. Admittedly in a Sinatra environment but it will work with Rails too. That and Xpath Class: REXML::XPath (Ruby 3.1.2) should work for you.

O.