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
✨ WIP: Add Kubernetes Gomega extension with to make testing controllers easier #1364
Conversation
This adds a utility that is intended to be used with envtest to make it easier for users to write tests. The Matcher wraps common operations that you might do with gomega when interacting with Kubernetes to allow simpler test assertions.
This should allow people to access fields within their objects fetched by the Matcher. This allows easier assertions by allowing specific fields to be compared during tests.
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: JoelSpeed The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/assign @vincepri Since I know you commented on the original issue I proposed. Looking for initial feedback on if this is something we still want to do and whether the interfaces seem reasonable. |
) | ||
|
||
// Matcher has Gomega Matchers that use the controller-runtime client. | ||
type Matcher struct { |
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 think Matcher should be unexported here, and the initialized struct should be returned as a non-pointer value from a builder method. With a repetitive and parallel nature of tests, it will be good to always know you work with unique komega interface using exact client, extras or timeout.
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.
Hmm that's a good point, at the moment we are using all pointer receivers, which means we will affect the parent. Perhaps we need to stop doing that and then whenever you call one of the builder style methods, it would not affect the parent it's being called upon, means you could compose different settings for each call if need be
I expect people will create a new matcher for each test anyway (either in a BeforeEach in Ginkgo or at the start of the test in normal test suites), a NewMatcher
method might make this cleaner though, good suggestion
) | ||
|
||
// Matcher has Gomega Matchers that use the controller-runtime client. | ||
type Matcher struct { |
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.
Hmm that's a good point, at the moment we are using all pointer receivers, which means we will affect the parent. Perhaps we need to stop doing that and then whenever you call one of the builder style methods, it would not affect the parent it's being called upon, means you could compose different settings for each call if need be
I expect people will create a new matcher for each test anyway (either in a BeforeEach in Ginkgo or at the start of the test in normal test suites), a NewMatcher
method might make this cleaner though, good suggestion
// Create creates the object on the API server. | ||
func (m *Matcher) Create(obj client.Object, opts ...client.CreateOption) gomega.GomegaAssertion { | ||
err := m.Client.Create(m.context(), obj, opts...) | ||
return gomega.Expect(err, m.extras...) |
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.
Currently, these will only work with the default package level gomega assertions, should make the option of passing in a custom gomega.WithT
as well to this can be used in normal go testing tests
Issues go stale after 90d of inactivity. If this issue is safe to close now please do so with Send feedback to sig-contributor-experience at kubernetes/community. |
/remove-lifecycle stale Would still like to contribute this at some point if it's useful. Additional feedback on the initial design would be appreciated |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
/lifecycle frozen This seems pretty useful, so I don't want this to be auto-closed by the ci-robot. @JoelSpeed is this still a WIP? If you're not actively making changes, it might be good to remove the WIP designation to signal reviewers that its ready for review. |
@joelanford: The In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
There's some feedback that I wanted to address about what's exported that probably shouldn't be, I'll try and get to that this week, then I'll remove the WIP tag |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-robot: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
This is an initial attempt at solving #933. I've revamped the design a little from the original to try and take into account some changes to the client since I originally came up with this idea.
Essentially this is a Kubernetes wrapper on top of Gomega to make it easy to write tests using envtest.
I've marked this as WIP at the moment as I would like to get some feedback on the initial design (and naming), and I would like to add docs on how to use this as well as tests to work as proof that the matchers work and as examples on how to implement it.
The outcome here is that inside a test, I should be able to write something like:
To check that my controller eventually reconciles my node and adds the taint specified. Or yanno, whatever you want to check. Internally, this will poll until the
Get
returns no errors and then return the node, and with theWithField
transform, allow me to extract particular fields and assert their values.