You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
the user's intent is almost always to flag the checkpoint but to keep running until testContext.succeedingThenComplete() is called with a succeeded future.
Currently, creating a checkpoint like in the above statement will actually end the test as soon as the test thread notices checkpoint.flag() (i.e. the injected testContext.awaitCompletion will be satisfied). This is very clunky.
Use cases
A common use case is to run some side-by-side check independent the test code and use checkpoints to flag that your assertions were actually run. For example you might mock a class and checkpoint.flag() inside a mocked method that runs assertions on its arguments.
Contribution
I can implement this feature.
The text was updated successfully, but these errors were encountered:
Yes, but what happens is the test completes beforesucceedingThenComplete 's returned handler is called, because of something with checkpoint.flag().
In my opinion, behavior should be, essentially:
Handler<AsyncResult<T>> succeedingThenComplete() {
return (ar) -> {/*if ar succeeded, wait until timeout for all remaining checkpoints to be passed.
otherwise fail.*/}
}
right now it's
inject a testContext
beginning of user's test code {
since the user called .checkpoint(),
the injected awaitCompletion will only wait for that one checkpoint to be flagged,
instead of the .completeNow() from .succeedingThenComplete()'s handler
} end of user's test code
inject awaitCompletion
Describe the feature
Given code like this:
the user's intent is almost always to flag the checkpoint but to keep running until
testContext.succeedingThenComplete()
is called with a succeeded future.Currently, creating a checkpoint like in the above statement will actually end the test as soon as the test thread notices
checkpoint.flag()
(i.e. the injectedtestContext.awaitCompletion
will be satisfied). This is very clunky.Use cases
A common use case is to run some side-by-side check independent the test code and use checkpoints to flag that your assertions were actually run. For example you might mock a class and
checkpoint.flag()
inside a mocked method that runs assertions on its arguments.Contribution
I can implement this feature.
The text was updated successfully, but these errors were encountered: