-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce wait-for instructions for rustdoc GUI tests #95172
Conversation
I’d really rather not mess with these numbers unless someone’s complaining about them becoming the long pole in the test suite. Making them shorter will increase the number of intermittent failures, when these tests run on a computer with a noisy neighbor. Could these tests be tweaked to poll for some criteria to be fulfilled, instead of just waiting for a fixed amount of time? For example, could the wait-for instruct be modified to take both a time and a selector? |
It already can. It's just that in some cases, waiting for a selector isn't working because the CSS changes associated to it haven't been computed by the browser yet. I only changed the biggest ones because the 1 second wait for example is just way too much. |
Could assert-css be extended with a timeout parameter, so that instead of just failing the first time it observed a failing match, it can instead poll for a while until it either observed a match or times out and fails? |
That could. Not sure if it's a good idea though... |
I've done browser UI tests (not with your framework, just Selenium-PHP), and wound up with a test suite that took hours to run while consuming less than 1% CPU. Redesigning it to use a function that pretty much does what "assert-css with a timeout param" would do improved it a lot, cutting runtime by more than half, while also pretty much eliminating intermittent test failures. But, on the other hand, that project was strange in a lot of ways, so I'm not sure how reflective of rustdoc it'll be. |
I could add a command |
Sure, that would be great. Thanks! |
I opened GuillaumeGomez/browser-UI-test#286. I'll try to do it in the next days. |
5757dfe
to
ec96926
Compare
ec96926
to
e0a697a
Compare
@notriddle Thanks to your great suggestion, almost all "random amount of time" waits have been removed! \o/ |
@bors r+ |
📌 Commit e0a697a has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (a2ebd5a): comparison url. Summary: This benchmark run did not return any relevant results. If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
r? @notriddle