Should add gotchas to testing with Capybara in README

[CharlieIGG]

I've been struggling for a while trying to create integration tests that dealt with this library.

There are two things that would've saved me (and hopefully would save other devs) a lot of time had they been documented here:

1. Waiting for Ajax requests. Although not specific to this library, there's no way to test without knowing how to do this, and it's not the most thoroughly or widely documented trick. This guide worked well for me: https://robots.thoughtbot.com/automatically-wait-for-ajax-with-capybara

2. Configuring the test server used by Capybara to prevent this from breaking: https://stackoverflow.com/questions/27992619/capybara-selenium-webdriver-datatables-not-playing-nicely is a good reference.

[n-rodriguez]

Hi there!

Thanks for your feedback! To answer you briefly :

1. Waiting for Ajax requests. Although not specific to this library, there's no way to test without knowing how to do this, and it's not the most thoroughly or widely documented trick.

I have integration tests with Capybara and I've never had to implement this kind of trick. Everything worked out of the box.

I suspect you might need this kind of trick when you want to test a Datatable with a lot of data, which can slow datatable rendering, due to long queries executions, and thus create errors during your tests. (cannot find tr with id 'foo' for example)

I usually have 3 or 4 entries in my datatables during integration tests, where I click on 'actions links' :

• edit link, which opens a modal box
• delete link, which calls the destroy action with UJS and reload the datatable
• etc...

and the datatables are always loaded in time.

But thanks for the hint since everyone might not be as lucky as I am 👍

2. Configuring the test server used by Capybara to prevent this from breaking

I admit it was one of the first thing I configured in Capybara. Since Puma is the default web server in Rails since Rails 5 (or so, can't remember) it was a non sense to me to not use it in tests ^^ (to avoid the usual story : it works in dev and not in test... yeah... dev uses Puma and test uses Webrick... ok)

About this specific point : https://stackoverflow.com/a/38705340

Use Puma and POST requests on a dedicated route : https://github.com/jbox-web/ajax-datatables-rails#use-http-post-method-medium

The 414 (Request-URI Too Large) errors are due to the using of the GET method.

With the default configuration, jQuery Datatables send requests with the GET method.
Everything works when you don't have too many columns or search fields in your datatable since all the data sent fit in the GET request (https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers)

The more columns you add in your datatable, the bigger the GET request will be.
And at some point, it will break with 414 (Request-URI Too Large).

To avoid that, and by the way to not pollute your Nginx logs with big HTTP requests, use POST, for all your datatables.

Use a dedicated route to do so. IMHO the index action is for rendering the index page, not a datatable.

With this and some little bits of metaprogrammig you can easily maintain tens of datatables.

[CharlieIGG]

Regarding point 1. I agree this might be too much of an edge case.

Regarding point 2. I totally missed this part https://github.com/jbox-web/ajax-datatables-rails#use-http-post-method-medium, and you're right. However I think it might be best to advise to configure Capybara to use Puma from the start. Closing this anyway, thanks @n-rodriguez

[n-rodriguez]

I'm adding both to the README ;) Thank you!