Removed all usages of old asserts and using the new StartEventRecord#3302
Conversation
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: slinkydeveloper The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
mattmoor
left a comment
There was a problem hiding this comment.
Produced via:
gofmt -s -w $(find -path './vendor' -prune -o -path './third_party' -prune -o -type f -name '*.go' -print)
|
cc @nlopezgi |
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
|
The following jobs failed:
Failed non-flaky tests preventing automatic retry of pull-knative-eventing-integration-tests: and 3 more. |
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
| if len(ev) != 0 { | ||
| t.Fatalf("Log is not empty in logger pod %q: %d events seen", loggerPodName, len(ev)) | ||
| t.Run(tc.name, func(t *testing.T) { | ||
| tc := tc |
There was a problem hiding this comment.
| client := setup(t, true) | ||
| defer tearDown(client) | ||
|
|
||
| // creates ServiceAccount and RoleBinding with a role for reading pods and events |
There was a problem hiding this comment.
So I understand, why did you pull this code from outside the loop to in here (might be a golang noob q, apologies if so)?
There was a problem hiding this comment.
Because the client setup in this way setup a context for each test, allowing the tests to run in parallel (before it had some race issues)
| t.Fatalf("Data %s, extension %q does not appear at least %d times in events of logger pod %q: %v", data, extensionSecret, expectedCount, loggerPodName, err) | ||
|
|
||
| } | ||
| eventTracker.AssertAtLeast(2, recordevents.MatchEvent( |
There was a problem hiding this comment.
One thing I have seen when using these assertions, is that the error messaging could be improved (not something that needs to happen in this CL, just commenting about it).
Specifically, I get messages like:
Expected messages not found: FAIL MATCHING: saw 0/1 matching events. recent events: (1 events seen, last N = [{ ... }]
The message shows me what events were observed, and that they failed to match 'something', but it does not tell me what it was actually matching for, why the events(s) did not match, or even where in the code to look for the matching. I ended up having to modify the matcher so that it printed to console more details.
There was a problem hiding this comment.
Agree and that should have improved it a bit https://github.com/knative/eventing/pull/3302/files#diff-719035a5ad84fc383e0dea6ef4c67e32R267
I'm not a fan of "logging" the matcher, because the code already describes it and it requires quite some work to log the matcher as string.
On the other hand, i don't get why I can't see the stacktrace that brings me to where the assertion is coded
There was a problem hiding this comment.
Though I agree with the feeling that logging the matcher is not ideal, the situation for debugging is not good as it is. Check for instance the matcher here: https://github.com/knative/eventing/blob/master/test/conformance/helpers/channel_tracing_test_helper.go#L341
I was not able to ever find out where the event that is passed to that match function is created. Could you help me locate it and help me understand how one goes from the matcher code, to the event instance, in a way that makes for this logging not strictly necessary.
There was a problem hiding this comment.
I was not able to ever find out where the event that is passed to that match function is created. Could you help me locate it and help me understand how one goes from the matcher code, to the event instance, in a way that makes for this logging not strictly necessary.
Ok TBH I don't get what you mean. How about getting this one in, see if the situation improved and then open a new issue to make it better? With this one we print the match failures, so that should be a beginning. What I wish now is to print the line where the Assert is invoked
There was a problem hiding this comment.
yeah, sgtm, my comment definitely does not block this PR.
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
|
/lgtm |
Signed-off-by: Francesco Guardiani francescoguard@gmail.com
Part of #3267
Proposed Changes
AssertWaitMatchSourceDatarecordevents.StartEventRecordOrFail(client, recordEventsPodName)