-
Notifications
You must be signed in to change notification settings - Fork 55
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
Don't do unnecessary condition evaluations in assertEventuallyTrueInGui #1168
Don't do unnecessary condition evaluations in assertEventuallyTrueInGui #1168
Conversation
CI is failing for unrelated reasons. I suggest that we pin our PySide6 version in CI in the short term. |
#1169 should fix the unrelated CI failures, so that we can see whether there are any related failures. |
Looks like this makes some existing macOS tests unhappy. Investigating. |
…ns-in-gui-test-assistant' into fix/spurious-condition-evaluations-in-gui-test-assistant
Marking as draft, since there seem to be some unexpected interactions with the |
…ext manager" This reverts commit 76e9cc6.
The failures for the font and color dialogs seem to be happening in the tests for the utility functions Possibly there is an issue with needed objects being gc'd or not cleaned up correctly? |
This should resolve #1170 as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good.
Thanks, @corranwebster. I'm happy for this to be merged if you are. |
…ui (#1168) `GuiTestAssistant.assertEventuallyTrueInGui` does an unnecessary extra `condition` evaluation after the event loop has exited. In the worst case, when the condition is only valid during a running event loop, this can cause spurious test failures. This PR updates the code so that it doesn't re-evaluate the condition once the condition has evaluated to `True` for the first time. Design note: the `bool()` call is in there to avoid hanging onto references in case the user-supplied condition returns something more complicated that a simple bool. --- EDIT: I've also updated the PR to use the `exit` method instead of the `quit` method within `event_loop_until_condition`; all we want here is to exit the event loop that was started using `self.qt_app.exec_` - not to tear down anything else. Co-authored-by: Corran Webster <cwebster@enthought.com>
…ui (#1168) `GuiTestAssistant.assertEventuallyTrueInGui` does an unnecessary extra `condition` evaluation after the event loop has exited. In the worst case, when the condition is only valid during a running event loop, this can cause spurious test failures. This PR updates the code so that it doesn't re-evaluate the condition once the condition has evaluated to `True` for the first time. Design note: the `bool()` call is in there to avoid hanging onto references in case the user-supplied condition returns something more complicated that a simple bool. --- EDIT: I've also updated the PR to use the `exit` method instead of the `quit` method within `event_loop_until_condition`; all we want here is to exit the event loop that was started using `self.qt_app.exec_` - not to tear down anything else. Co-authored-by: Corran Webster <cwebster@enthought.com>
GuiTestAssistant.assertEventuallyTrueInGui
does an unnecessary extracondition
evaluation after the event loop has exited. In the worst case, when the condition is only valid during a running event loop, this can cause spurious test failures.This PR updates the code so that it doesn't re-evaluate the condition once the condition has evaluated to
True
for the first time.Design note: the
bool()
call is in there to avoid hanging onto references in case the user-supplied condition returns something more complicated that a simple bool.EDIT: I've also updated the PR to use the
exit
method instead of thequit
method withinevent_loop_until_condition
; all we want here is to exit the event loop that was started usingself.qt_app.exec_
- not to tear down anything else.