-
Notifications
You must be signed in to change notification settings - Fork 380
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
tests: introduce end-to-end test framework #226
Conversation
158ff4a
to
dbcfacb
Compare
a75c224
to
25fb560
Compare
25fb560
to
d578a52
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks William.
I have some minor questions/comments, but otherwise LGTM.
func (rc *RPCChecker) CheckWithFilters(connTimeout time.Duration, allowList, denyList []*tetragon.Filter) features.Func { | ||
return func(ctx context.Context, t *testing.T, _ *envconf.Config) context.Context { | ||
rc.lock.Lock() | ||
defer rc.lock.Unlock() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering why is this lock needed? AFAICT, it is only used in this function. Can this function be called concurrently from different goroutines? If so, this seems weird to me because I assumed we had one checker that talks to the multiplexer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If memory serves I was concerned about test authors using the same checker multiple times in a single testenv.TestInParallel. (Which runs its feature funcs concurrently.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So maybe a comment here? to prevent accidental changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was concerned about test authors using the same checker multiple times in a single testenv.TestInParallel.
I see. Out of curiosity, how would one go about doing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kkourt testenv.TestInParallel(workloadFeature, checkerFeature, checkerFeature, checkerFeature /* etc... */)
addrs = append(addrs, fmt.Sprintf("localhost:%d", port)) | ||
} | ||
|
||
if rc.getEvents == nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this be not nil? Can we enter the CheckWithFilters
with .connect() already called? (AFAICT, this is the only place that getEvents is set)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case where we want to use the same checker more than once we keep the original connection open. Useful for example when we want to run the same workload multiple times in a stress test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the case where we want to use the same checker more than once we keep the original connection open. Useful for example when we want to run the same workload multiple times in a stress test.
Similar to my previous comment. How would one go about doing this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kkourt just stick the workload + checker features in a for loop. For example you could imagine a TestKprobeNTimes test or something similar that runs the same test 1, 10, 20, etc. times in a row to check for flakes.
d578a52
to
2bd41df
Compare
Looks like 4dac275 causes Tetragon to fail the skeleton test :( |
8725bb1
to
ec08611
Compare
f5db4e3
to
6d63a18
Compare
@willfindlay since you seem to be still working on it, I'll move it to draft. Please mark it as ready when you feel it's ready to be merged. |
6d63a18
to
02172ca
Compare
02172ca
to
94c965f
Compare
@kkourt I think it's in a good state to ship it now. I'll leave it for you just in case you want to do another round of comments in the morning. |
This PR introduces a new end-to-end test framework in `tests/e2e` which we can use to write cross-provider end-to-end tests for Tetragon. The tests themselves live in `tests/e2e/tests`. I have added a skeleton file with lots of comments that folks can use as a starting point for writing new tests. Updated the Makefile to support e2e-tests by adding a separate e2e-test target and making sure that regular `make test` will not call into the e2e-tests by pointing it directly at `./pkg/...`. Also added an EXTRA_TESTFLAGS variable to the Makefile that can be used to pass flags directly to the test binary from either a `make test` or `make e2e-test`. Signed-off-by: William Findlay <[email protected]>
Add a basic job to run end-to-end tests in CI using a KinD cluster. Signed-off-by: William Findlay <[email protected]>
94c965f
to
158dd23
Compare
This PR introduces a new end-to-end test framework in
tests/e2e
which we can use towrite cross-provider end-to-end tests for Tetragon. The tests themselves live in
tests/e2e/tests
. I have added a skeleton file with lots of comments that folks can useas a starting point for writing new tests.
Updated the Makefile to support e2e-tests by adding a separate e2e-test target and making
sure that regular
make test
will not call into the e2e-tests by pointing it directly at./pkg/...
. Also added an EXTRA_TESTFLAGS variable to the Makefile that can be used topass flags directly to the test binary from either a
make test
ormake e2e-test
.The plan is to use this new framework to start writing e2e tests for Tetragon features.