-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Improve the behavior of require
assertions when using assert.EventuallyWithT
#1396
Comments
Maintenance work on testify is huge. Please ease work of the maintainers by providing an example running on the Go Playground. Here is a template: https://go.dev/play/p/hZ3USGA87Fk |
Sure, I have created an example to showcase the current behavior (panic): https://go.dev/play/p/YiRjPaHFMr1 |
It seems that some assertions will call `FailNow()` which panics when called on `assert.CollectT`. See: - stretchr/testify#1396 - stretchr/testify#1457
It seems that some assertions will call `FailNow()` which panics when called on `assert.CollectT`. See: - stretchr/testify#1396 - stretchr/testify#1457
This is good improvement on |
Consider the following use of
EventuallyWithT
.Here the intention is to fail
assert.EventuallyWithT
immediately if therequire.NoError
assertions fails. Instead this code will panic ifmyFunc()
returns an error. This is because of how theFailNow
method is implemented on theCollectT
object:testify/assert/assertions.go
Lines 1872 to 1875 in f97607b
The panic ensures that the call to the
condition
function "exits" immediately. However it will immediately interrupt test execution.It feels like the implementation could be improved, so that it immediately fails the
assert.EventuallyWithT
assertion, without crashing the test.There are 2 possible implementations IMO:
FailNow
implementation as follows:The relevant code in
EventuallyWithT
could then look like this:recover
inEventuallyWithT
to recover from the panic. I am not going into too many details here, as I think the other solution is better. Panics can be cause by user code in thecondition
function, and we probably don't want to recover from these.If the new suggested behavior is not acceptable, I'd like to understand the rationale for the current implementation.
cc @tnqn
The text was updated successfully, but these errors were encountered: