Blog: Creating an e2e test for conformance#22
Conversation
|
👍 |
zachmandeville
left a comment
zachmandeville
left a comment
There was a problem hiding this comment.
Great post! I liked following Daemonset through the whole process. There were just a few awkwkard phrasings or typos that I've marked in the comments.
|
|
||
|  | ||
|
|
||
| The process starts by using [APIsnoop](https://github.com/cncf/apisnoop) (which uses a postgres database containing audit logs from e2e test runs) to identify a set of untested endpoints that are part of the stable API endpoints. During this process various groups or patterns of endpoints are discovered. One such group of endpoints are “DaemonSetStatus”. The journey starts with exploring these endpoints, creates an e2e test that exercises each endpoint before it’s merged into the K8s repo. |
There was a problem hiding this comment.
the last sentence feels unclear to me, and "journey" is perhaps redundant to the opening "process". Maybe something like:
"Next we will explore these endpoints, create an e2e test that exercises each of them, then merge this test into the k8s repo."
| Type of DaemonSet condition. | ||
| ``` | ||
|
|
||
| 3. Lastly, using both [APIsnoop in cluster](https://github.com/cncf/apisnoop/tree/main/kind) while reviewing the current [e2e test suite](https://github.com/kubernetes/kubernetes/tree/master/test/e2e) for existing conformance tests that test a similair set of endpoints. In this case we used [a Service Status test](https://github.com/kubernetes/kubernetes/blob/7b2776b89fb1be28d4e9203bdeec079be903c103/test/e2e/network/service.go#L2300-L2392) as a template for the new Daemonset test. |
There was a problem hiding this comment.
similair -> similar
|
|
||
| ## Validating the e2e test | ||
|
|
||
| Using `go test` we can run just a single test for quick feedback |
There was a problem hiding this comment.
remove "just" to make the sentence flow a bit easier.
|
|
||
| # Final Thoughts | ||
|
|
||
| The current workflow and tooling provides a high level of confidence when working through each e2e test. Following agreed coding patterns, styles and processes helps to minimise possible issues and test flakes. There’s always an opportunities to get support through GitHub tickets, [various Kubernetes slack channels](https://kubernetes.slack.com/messages/k8s-conformance) and conformance meetings. |
There was a problem hiding this comment.
"there's always an opportunities": change to something like "there's always opportunities"
|
|
||
| The current workflow and tooling provides a high level of confidence when working through each e2e test. Following agreed coding patterns, styles and processes helps to minimise possible issues and test flakes. There’s always an opportunities to get support through GitHub tickets, [various Kubernetes slack channels](https://kubernetes.slack.com/messages/k8s-conformance) and conformance meetings. | ||
|
|
||
| Every e2e test that’s merged and then promoted to conformance requires the input from a wide range of people. Thanks to the support from community reviewers, SIGs and the direction provided by SIG-Architecture this work is possible and very rewarding. |
There was a problem hiding this comment.
We can punch up the last sentence a bit, maybe:
"It is thanks to the support from community reviewers, SIGS, and the direction of SIG-Architecture that this work is not just possible, but rewarding."
3 participants
Covers the journey of an untested endpoint to an e2e test.