-
Notifications
You must be signed in to change notification settings - Fork 117
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
Rework how tests deal with future timeout #496
base: main
Are you sure you want to change the base?
Conversation
❌ Integration test FAILEDRequested by @var-const on commit e5b44cf
|
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.
Overall, this looks fantastic! It's great to see the timeout logic de-duplicated in several places. Thanks for doing this.
// occurs. Returns `true` on success, `false` on timeout or if exit signal was | ||
// received. | ||
template <typename PredT> | ||
bool WaitUntil(const PredT& pred, int timeout_ms = kTimeOutMillis); |
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.
Consider returning an enum from WaitUntil()
and WaitUntilFutureCompletes()
instead of conflating timeout and exit signal with a false
return value. This will improve readability at the call sites since it is not immediately obvious without reading the function's documentation or implementation what the return value means and will avoid misleading "timeout" error messages when the exit signal occurs.
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.
I thought about this but was leaning towards not doing it. It seems to complicate the common case for the sake of a very rare occurrence. I'm not sure this even works correctly -- e.g. on Linux the integration tests seem to completely ignore Ctrl-C
.
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.
I'm not sure this even works correctly -- e.g. on Linux the integration tests seem to completely ignore Ctrl-C.
Please disregard -- this is actually working correctly. I'm still hesitant to complicate the common case, though.
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.
Hmm, it seems like it actually works in some tests and doesn't work in others.
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.
My concern still stands, that returning a bool
detracts from readability at the call sites. And confounding exit signal with timeout could lead to misleading test failure messages. When tests timeout they are already hard enough to debug and unclear error messages can further make that harder. This doesn't block my approval of this PR though.
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.
It seems to me that the root cause here is that these functions just don't have a great way of reporting this event, which really seems more akin to an exception. There also isn't much tests can do about it, so I'm not sure they need the ability to check for this condition. I think that this type of exit usually happens due to user input, so it shouldn't be confusing to the user, at least in the general case.
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.
Maybe we should throw an exception now that exceptions are enabled in tests, especially once #561 is merged. In any case, that's out of scope for this PR so I'm fine with this code as-is.
@@ -280,37 +285,27 @@ class FirestoreIntegrationTest : public testing::Test { | |||
|
|||
// TODO(zxu): add a helper function to block on signal. | |||
|
|||
// A helper function to block until the future completes. | |||
// Blocks until the future completes and returns the future result. |
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.
ultranit: Consider adding a comma after "completes".
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.
Hmm, my understanding is that this is a compound predicate (Blocks... and returns
) and thus doesn't require a comma. I can't dig up a very authoritative reference quickly but the few links that come up in a search seem to agree -- see e.g. this.
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.
You may be technically correct. For me, every time I read this sentence I read "Blocks until the future completes and returns" which implies that the future "completes and returns" but "returns" actually gets associated with the text that follows. Totally up to you though :)
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.
Ah, I see what you mean, and I fully agree. How about Blocks until the future is completed and returns...
? I think it could still be read the wrong way but it seems like an improvement. What do you think?
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.
Or, you could add a comma after "completes" ;) I think without the comma any wording has some ambiguity.
// This function is found dynamically by googletest to print a Future object | ||
// in a test failure message. | ||
void PrintTo(const Future<void>& future, std::ostream* os); | ||
// This function is via ADL by Googletest to print a Future object in a test |
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.
I think there is a missing verb in this sentence: "This function is via ADL...". Should it be "is found"?
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.
Approved, with one very minor comment about a comment wording.
@dconeybe Is this PR still relevant? Should it be merged or closed? |
🍞 Dismissed stale approval on external PR.
Yes, it is still relevant. I've merged in HEAD and assigned to myself. |
Merge could not be authorized
Also fix a potential bug in
DescribeFailedFuture
(error_message()
can return null).