n-rodriguez
commented
6 years ago 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' :
editlink, which opens a modal boxdeletelink, 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 :+1:
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
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:
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
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.