-
Notifications
You must be signed in to change notification settings - Fork 68
🌱 Flakes: replace require with assert in retry funcs
#1330
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
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 <[email protected]>
✅ 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 <[email protected]>
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 <[email protected]>
Description
When
requireassertions are not satisfied they fails a test immediately. This is not desired when usedwith retry function such as
EventuallyWithTsince 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
requirewill failEventuallyWithTdespite the fact that the code is correct and the condition gets set eventually.Example failures from today & yesterday:
Reviewer Checklist