Bug 33861 - Packages_spec.ts is failing randomly
Summary: Packages_spec.ts is failing randomly
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Test Suite (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low normal
Assignee: Chris Cormack
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks: 25551
  Show dependency treegraph
 
Reported: 2023-05-30 09:09 UTC by Jonathan Druart
Modified: 2024-02-14 15:30 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Druart 2023-05-30 09:09:58 UTC
It is currently failing on Koha_Master/2534

koha_1       |     1) Delete package
koha_1       | 
koha_1       | 
koha_1       |   4 passing (35s)
koha_1       |   1 failing
koha_1       | 
koha_1       |   1) Package CRUD operations
koha_1       |        Delete package:
koha_1       |      AssertionError: Timed out retrying after 10000ms: Expected to find element: `#packages_list table tbody tr:first td:first a`, but never found it.
koha_1       |       at Context.eval (http://kohadev-intra.mydnsname.org:8081/__cypress/tests?p=t/cypress/integration/ERM/Packages_spec.ts:373:19)
Comment 1 Pedro Amorim 2023-05-30 10:51:37 UTC
Unable to reproduce locally.

I may be wrong but this looks like one of those "happens once every full moon" test failures.
Comment 2 Jonathan Druart 2023-05-30 11:30:20 UTC
(In reply to Pedro Amorim from comment #1)
> I may be wrong but this looks like one of those "happens once every full
> moon" test failures.


Yes, hence the "randomly" in the bug title ;)
Comment 3 Victor Grousset/tuxayo 2023-08-14 02:45:46 UTC
> Unable to reproduce locally.

Depending on the machine the failure probability can be drastically different. My laptop that is showing it's age (2012 CPU) has 0% probability of running all the cypress tests successfully all in a row. I usually have two or three files failing. And then by running them again individually, I can expect to have a success by running them 3 or 5 times for the one or two that fails easily.
So I can easily tests patches for flaky tests [1]. Best would be to give a go at fixing them.

What are the tricks we can use with Cypress to make them more reliable? (besides adding horrible sleep() instructions).
I guess adding check for elements that should load earlier?
Like ensuring a list has loaded it's elements because a button might be there before and would be clickable even if the callback has 0 associated targets.


[1] maybe anyone can do so by running at the same time "stress --cpu 4". With the right amount of threads, maybe leaving only one of two would work best, the point is not to hit the 10 sec timeout in every test instruction.