Remove call to non-existent method & fix system tests

[r-ferrier]

Fixes #1754
Fixes #2116

Description

Originally this PR just updated a line with a call that will destroy the table, following the datatables documentation https://datatables.net/reference/option/destroy. Updating this flagged up an area of our tests that are really unreliable - system tests. I wrote a rake task to allow me to run tests multiple times locally and log the number of failures, as I tried tinkering with the wait times in our helpers. The results of this were:

• first test - 15 second wait - 4/10 passed
• second test - 20 second wait - 0/10 passed
• third test- 25 second wait - 1/10 passed
• fourth test - 30 second wait - 3/10 passed
• fifth test - 60 second wait - 1/10 passed
• fifth test - 120 second wait - 3/10 passed

Just increasing the time we wait for things to happenI looked through the test failures and found that most of the fails were due to not finding a datatable element on the calendar (possibly something introduced in this PR given the frequency of the failures) or elements going stale. I've added two new helper methods to catch these exceptions and retry when they happen, to try to prevent tests failing as often as they are. Where an action is being repeated I have reduced the wait times slightly. The helpers will retry up to 5 times, which is hopefully enough to evade flakiness but still finish in a timely manner if something is genuinely broken.

I'll add the code I used for the rake task in as a comment - don't want to commit it and clog up the repo but it was useful!

[ivan-kocienski-gfsc]

Looks good to me (doesn't raise exception in the web console)

[r-ferrier]

This PR is failing again and again and again on system tests. I'm not sure what to do with it! It's failing different ones each time which makes no sense to me. It passed after 7 tries before. Does data persist between system test runs? Is it something to do with the order they're running in?

[ivan-kocienski-gfsc]

To answer your question: no data should not be shared / cached between runs, all it is doing is spinning up the rails server, starting a browser and poking things in the browser.

I think flaky integration tests are just a hazard as they are reliant on the performance of the CI server running the code (because the browser has no "direct" link to the app server running our code).

Digging in it looks like assert_select2_multiple is the hangup (find() on line 38) - I think its find that guy.

Looks like wait is set to default_max_wait_time which is set to 2 which is too small so maybe try changing that line to something like

rendered = find(:css, '.select2-selection__rendered', wait: 30).text.delete('×').delete("\n")

[r-ferrier]

hmmm I'm not sure - it's failed for lots of different reasons - that's just the reason it failed this time around. Good to know it's not an order thing though.

I know the tests are flaky but I think this latest fail is at least number 10, out of 11 runs - that feels like more than just bad luck? This PR is datatable related and there is lots of datatable related interaction in the system tests so could it be something related to that?

[r-ferrier]

A useful rake task for batch running system tests and reporting results

desc 'run tests multiple times'
task :batch_test do # rubocop:disable Rails/RakeEnvironment
  number_of_test_runs = 10
  pass_count = 0
  10.times do |_|
    sh('rails test:system') && pass_count += 1
  rescue StandardError
    nil
  end
  puts '-------------'
  puts "Number of passes = #{pass_count}/#{number_of_test_runs}"
  puts '-------------'
end