Reputation: 4787
I have operationnal tests to check that the right message is displayed in a Rails UJS/ajax modal for error 404, 500... Here is an example below (the test below passes; I'm using puffing billy gem to stub the ajax response)
it " displays correct modal message appears correctly after relevant 500 xhr / ajax response is received" do
visit deal_page_path(deal)
proxy.stub("http://127.0.0.1:59533/deals/dealname/thrill").and_return(:code => 500)
first('a.button').click
wait_for_ajax
within('ul.messenger') do
expect(page).to have_content('So sorry, we had a bug, try again')
end
end
But I fail to test that the correct message is displayed when the problem is a timeout: indeed i don't stub inside rspec that the response sent by ajax is a timeout because Chrome/webkit actually does not send headers nor an "easy" code like 500 but sends the status (canceled).
I tried with no success:
proxy.stub("http://127.0.0.1:59533/deals/dealname/thrill").and_return(:status => 'canceled')
proxy.stub("http://127.0.0.1:59533/deals/dealname/thrill").and_return(:status => '(canceled)')
Note: not sure it's related to the same chrome/webkit behavior but I saw this post: What does status=canceled for a resource mean in Chrome Developer Tools?
Upvotes: 2
Views: 281
Reputation: 49910
There is no http status code for the timeout you're talking about since the timeout is specifically that no http status code was returned in that timeframe. There are some status codes that may be returned by proxies if their upstream connections timeout but I think thats different than what you're testing. I responded on your other question about how to get puffing billy to make a connection take longer than your timeout setting - Rails - How to stub a certain response time for a stubbed / fake http or ajax response
Upvotes: 1