Investigate the spurious testing suite

[jb3]

As of recent, the testing seems more spurious than ever, with errors that now appear to be persistent cropping up despite no changes to dependencies or anything in the test suites taking place.

=========================== short test summary info ============================
FAILED assets/tests/test_interaction.py::test_search - selenium.common.exceptions.StaleElementReferenceException: Message: stale element reference: stale element not found
[...]
FAILED assets/tests/test_interaction.py::TestAssetList::test_asset_order - selenium.common.exceptions.StaleElementReferenceException: Message: stale element reference: stale element not found
[...]
FAILED assets/tests/test_interaction.py::TestSupplierList::test_search - AssertionError: False is not true
FAILED users/tests/test_users.py::UserRegistrationTest::test_registration - selenium.common.exceptions.StaleElementReferenceException: Message: stale element reference: stale element not found
[...]
FAILED RIGS/tests/test_interaction.py::TestCalendar::test_ics_files - django.db.utils.OperationalError: database table is locked
====== 5 failed, 120 passed, 3 skipped, 310 warnings in 161.25s (0:02:41) ======

I am unsure why these 5 tests seem to stay stuck as failed, especially when nothing has been touched related to them. One thing they appear to have in common is that for a few of them a page-reload/DOM change happens (which obviously triggers the error there) but I am unsure why that is now posing an issue/what the best way to mitigate this is (fetch certain items from the DOM again).

An example build log with these failures is located here: https://github.com/nottinghamtec/PyRIGS/actions/runs/13888840157/job/38859139876

The test_search function may have something deeper broken since it is not a stale error but I suspect it is related to some sort of delay. Similarly, the ICS test is failing due to the SQLite database being locked, I am not sure of the best way to mitigate that (test against PostgreSQL? 🤣 ¹).

Footnotes

1. Only half joking... we do this for python-discord/site, another Django project I maintain, and the tests are completely reproducible. ↩

[FreneticScribbler]

FWIW I have always thought that testing against SQLite when we run Postgres in production is dumb. Doubly so when it causes test failures through database locking. I could just never be bothered to change it. 😅