-
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
🌱 Remove ginkgo from internal/controller unit tests #541
🌱 Remove ginkgo from internal/controller unit tests #541
Conversation
bf9f30c
to
dced08b
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #541 +/- ##
=======================================
Coverage 83.69% 83.69%
=======================================
Files 20 20
Lines 822 822
=======================================
Hits 688 688
Misses 92 92
Partials 42 42
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
ctx, cancel := context.WithCancel(context.Background()) | ||
defer cancel() | ||
|
||
invalidChannels := []string{ |
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.
General comment for this and the lists of semver ranges above - what are we testing? Is it validating admission? If so - there are straightforward ways to unit-test that logic that will be orders of magnitude faster than this. Lists such as these look like the wrong level of abstraction to test in integration tests.
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.
This is a direct translation of the existing tests. I'm not looking to change the nature of the tests here.
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, there's a set of validatior
tests in a subdirectory of this, to which these can probably be moved.
That's a much smaller translation, so I'd be willing to add these tests to there.
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.
And my recollection is that the complex regex used to validate these semvers may be a bit lenient, so this is a more thorough 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.
That appears to be the case, not all of these can be easily validated by the admission validation (see #542 https://github.com/operator-framework/operator-controller/pull/542/files#diff-6af2fcdc11cc7d43e85d42a4926bfa2ffd47e2292b09ba20407ba78b0f34c3d1R74), so these need to be left here, as they are testing the parsing code during reconciliation.
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.
Are you saying we should not test a complex regex? Or are you saying there's a better way to test the regex?
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.
ping @stevekuznetsov
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.
Sorry, missed this - let's keep it for now but open an issue to do it at the unit level. If you follow this code you can see how to generate a validator for a structural schema. Then you can run this a couple orders of magnitude faster and without network hops. I don't think it's good for anyone to run unit-level validations in e2e.
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.
A reminder that this is unit tests. The e2e tests are in #545
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.
Issue: #549
@stevekuznetsov I would much prefer to get this in as a direct translation, and then optimize later. |
Why? If we know we want the "optimizations", what are we (the group) gaining by merging this PR today as opposed to merging the PR + the comment responses tomorrow? |
TBH, I think it's easier to review, at least when making changes such as table-based tests. I can certainly remove the unnecessary clean up. |
I don't (personally) mind the review burden, as even with the current commit I had to read the diff side-by-side instead of interleaved. You could always put multiple commits in the PR if you wanted to document intermediate states. |
I'm ok with splitting it up into multiple commits, if you don't mind the review burden. |
ca58fef
to
7c94479
Compare
@stevekuznetsov this should address your concerns. |
ctx, cancel := context.WithCancel(context.Background()) | ||
defer cancel() | ||
|
||
invalidChannels := []string{ |
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.
Hm, I'd still wonder, though - if we are issuing a CREATE and expecting it to fail, what mechanism causes that? If it's validating admission from the structural schema on the CRD, the underlying mechanism should be that exact regex we've specified in the kubebuilder comment. I don't fully grok how this test can be more specific than a unit test of validating admission specifically.
t.Log("It results in the expected BundleDeployment") | ||
bd := &rukpakv1alpha1.BundleDeployment{} | ||
require.NoError(t, cl.Get(ctx, types.NamespacedName{Name: opKey.Name}, bd)) | ||
require.Equal(t, "core-rukpak-io-plain", bd.Spec.ProvisionerClassName) |
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.
The one further thing that would bring this more inline with common patterns would be to assert on a specific structure -
require.Empty(cmp.Diff(bd.Spec, operatorsv1alpha1.BundleDeploymentSpec{ ... }))
IMO this makes writing assertions more compact, and the output errors are about 10,000x better - right now if this line fails you have to go read the code to figure out what field "core-rukpak-io-plain"
was supposed to be in.
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.
require.Equal
of the whole structure might be better than adding cmp.Diff
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.
require.Empty+cmp.Diff is waaaaaay better than require.Equal. If you get a test failure, it is orders of magnitude easier to diagnose the difference using the cmp.Diff approach.
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.
Learning something new! I'll look into it if I have time.
}) | ||
}) | ||
// this bypasses client/server-side CR validation and allows us to test the reconciler's validation | ||
fakeClient := fake.NewClientBuilder().WithScheme(sch).WithObjects(operator).WithStatusSubresource(operator).Build() |
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.
Not something you need to change here but we might want to queue this up for discussion later, this test case seems a bit wild.
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 didn't originally write most of these tests! :)
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.
Yep! Undersood :)
30ca688
to
61783da
Compare
Fix operator-framework#190 Signed-off-by: Todd Short <[email protected]>
Signed-off-by: Todd Short <[email protected]>
Signed-off-by: Todd Short <[email protected]>
Signed-off-by: Todd Short <[email protected]>
Signed-off-by: Todd Short <[email protected]>
Signed-off-by: Todd Short <[email protected]>
a6ecb2a
to
bd389d8
Compare
Fix #190
This also puts back some of the post-testing cleanup.
Description
Reviewer Checklist