-
Notifications
You must be signed in to change notification settings - Fork 535
Adding tests for syncing service endpoint and endpointslice to host #3187
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
base: main
Are you sure you want to change the base?
Conversation
8f1fb9a to
dbc7868
Compare
9646794 to
cd0c636
Compare
cd0c636 to
49483fb
Compare
|
|
||
| translatedServiceName := translate.SingleNamespaceHostName(serviceName, serviceNamespace, translate.VClusterName) | ||
|
|
||
| ginkgo.By("Verify Service exists in Host Cluster") |
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 noticed this is only a check about existence. But is this sufficient? I'd test also the content of the objects. E.g. the presence of the input values from above:
Ports: []corev1.ServicePort{
{
Name: "custom-port",
Port: 8080,
Protocol: corev1.ProtocolTCP,
TargetPort: intstr.FromInt(5000),
},
},
This also applies to the endpoint object.
|
|
||
| ginkgo.Context("Verify endpoint sync when endpoint is deployed before service", func() { | ||
| ginkgo.It("Should sync Service, Endpoints, and EndpointSlice from vCluster to host cluster", func() { | ||
| ctx := f.Context |
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.
nit: usage of ctx vs. f.Context is not consistent. The object creations use .Create(f.Context, ... and all other use .Get(ctx, ...
|
|
||
| ginkgo.By("Create Service Endpoint in vCluster") | ||
| _, err := f.VClusterClient.CoreV1().Endpoints(serviceNamespace).Create(f.Context, testEndpoint, metav1.CreateOptions{}) | ||
| framework.ExpectNoError(err) |
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'd always prefer gomega.Expect(err).To(gomega.Succeed()) over framework.ExpectNoError(err)` because:
- it delivers way more context in case of failure. E.g. the whole nested error chain instead of only the aggregated error message.
- it is universal, can be used in any test, not only the once using
framework.
But this is personal preference, feel free to just close this comment in case of disagreement.
What issue type does this pull request address? (keep at least one, remove the others)
/kind test
What does this pull request do? Which issues does it resolve? (use
resolves #<issue_number>if possible)For eng-6661