Replies: 3 comments 1 reply
-
|
Because Cypress can imitate user interaction, some tests will inevitably include things like fake delays, wait for UI animations to complete, wait for page load, etc. These types of slowdown will get more frequent as more tests are added... |
Beta Was this translation helpful? Give feedback.
-
|
If we make the things in the bullet list separately runnable (via options), we can parallelize them into separate CI runs on GitHub. |
Beta Was this translation helpful? Give feedback.
-
|
it makes sense to parallelize the cypress and selenium tests from other things, but not as much the html validation from the rest of the tests (as the html validation runs all of those same tests anyhow). |
Beta Was this translation helpful? Give feedback.
-
|
This is over a year old - I'm going to close it - we will schedule work in the future (off the end of the horizon at the moment) to rework the test framework anyhow so we can run just the TestCase tests in parallel. |
Beta Was this translation helpful? Give feedback.
-
(Bringing several individual conversations together)
The tests as we currently have them defined, especially with the addition of the v.Nu validator in feat/bs5 are taking far too long to run. We can pursue making them more efficient, but until we find a breakthrough on that front, we probably need to change how we are planning to use them.
The proposals I've heard so far intersect on something like this:
Question: should we treat cypress the same way (--with-cypress-tests) or is it efficient enough to run in the default test suite Right now, there are so few cypress tests it's hard to know.
Beta Was this translation helpful? Give feedback.
All reactions