-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add mechanism for accurate, isolated unit tests calling Reconcile directly #2358
Comments
Also sharing here because it's related to the discussion: https://cluster-api.sigs.k8s.io/developer/testing.html
We had a similar experience in ClusterAPI. On one side it's more realistic that way, on the other side this lead to many flaky unit tests. |
/kind support feature |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues 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. This bot triages un-triaged issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close not-planned |
@k8s-triage-robot: Closing this issue, marking it as "Not Planned". 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. |
My team is writing reconciler unit tests which use fake.Client and call Reconcile directly. These tests have been a great benefit to developer velocity because they are easy to write using standard go testing, run quickly and accurately, and don't require dependencies.
In many cases, it is suggested to use envtest rather than the fake client for a few reasons:
However, there are some issues:
@vincepri suggests (#2341 (comment)) using the cache's
DefaultLabelSelector
feature to isolate test cases from each other. I wrote some exploratory code creating wrapped clients which use theDefaultLabelSelector
to isolate test cases and automatically add the labels during Create operations. It works well enough, but has some drawbacks:I'd like to discuss testing strategies for these cases and see if we can improve. Here are some quick opportunities and thoughts:
DefaultLabelSelector
support to client.Client and provide an isolated client wrapper which adds the label on Create. This seems to be a decent option.Whatever option is best, I'd like to help contribute and help document the best approach.
Thank you :)
The text was updated successfully, but these errors were encountered: