-
Notifications
You must be signed in to change notification settings - Fork 54
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
🌱 Flakes: replace require
with assert
in retry funcs
#1330
🌱 Flakes: replace require
with assert
in retry funcs
#1330
Conversation
When `require` assertions are not satisfied they fails a test immediately. This is not desired when used with retry function such as `EventuallyWithT` since they are supposed to retry on a failure. This can cause flakes when, for example, we are asserting on a resource condition. On the first hit the resource might not have a condition and `require` will fail `EventuallyWithT` despite the fact that the code is correct and the condition gets set eventually. Signed-off-by: Mikalai Radchuk <mradchuk@redhat.com>
✅ Deploy Preview for olmv1 ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
require
with assert
in retry funcsrequire
with assert
in retry funcs
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1330 +/- ##
==========================================
- Coverage 76.17% 76.13% -0.05%
==========================================
Files 41 41
Lines 2409 2409
==========================================
- Hits 1835 1834 -1
- Misses 401 402 +1
Partials 173 173
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Can we generalize the statement that we should not use I know this is just test code, but the extra lines are messing with my OCD. 😉 require.EventuallyWithT(t, func(ct *assert.CollectT) {
assert.NoError(ct, c.Get(context.Background(), types.NamespacedName{Name: clusterExtension.Name}, clusterExtension))
cond := apimeta.FindStatusCondition(clusterExtension.Status.Conditions, ocv1alpha1.TypeProgressing)
if assert.NotNil(ct, cond) {
assert.Equal(ct, metav1.ConditionFalse, cond.Status)
assert.Equal(ct, ocv1alpha1.ReasonSuccess, cond.Reason)
}
}, pollDuration, pollInterval) |
ab99642
While reviewing operator-framework#1330 we had a discussion about the ability to generally prevent the use of `requires` within `Eventually` calls to prevent future flakes, and that led us to evaluate the `testifylint`-er to give us some cautionary guidelines. It did _not_ resolve the requires-within-eventually issue, but we may try to tackle that with some custom AST in the future. Signed-off-by: Jordan Keister <jordan@nimblewidget.com>
While reviewing #1330 we had a discussion about the ability to generally prevent the use of `requires` within `Eventually` calls to prevent future flakes, and that led us to evaluate the `testifylint`-er to give us some cautionary guidelines. It did _not_ resolve the requires-within-eventually issue, but we may try to tackle that with some custom AST in the future. Signed-off-by: Jordan Keister <jordan@nimblewidget.com>
Description
When
require
assertions are not satisfied they fails a test immediately. This is not desired when usedwith retry function such as
EventuallyWithT
since they are supposed to retry on a failure.This can cause flakes when, for example, we are asserting on a resource condition. On the first hit the resource might not have a condition and
require
will failEventuallyWithT
despite the fact that the code is correct and the condition gets set eventually.Example failures from today & yesterday:
Reviewer Checklist