This is a chicken and egg problem, since the resources package didn't exist when most of this was written (but it did for Route, which I avoided because of the v1alpha3 work). As a result, when I wrote the Route controller's table tests, I was able to take advantage of the resources package to synthesize the assorted child resources based on the input revision.
I think the pattern I like the most is:
- Write test helper methods for synthesizing the core resource in the appropriate state (e.g.
rev("foo", "bar", "Active", "image") in revision/table_test.go)
- Populate the
Listers (input state), WantXYZ entries (output state) via resources.MakeFoo(...) where the same helper method is used to supply the core resource again.
- For both the core resource and these child resources, write helper methods to mutate them into the states needed for different test cases (e.g.
addConfigLabel, mutateService, ...)
I think this gets us the tersest expression of the table test that conveys what we want.
This is a chicken and egg problem, since the
resourcespackage didn't exist when most of this was written (but it did for Route, which I avoided because of the v1alpha3 work). As a result, when I wrote the Route controller's table tests, I was able to take advantage of theresourcespackage to synthesize the assorted child resources based on the input revision.I think the pattern I like the most is:
rev("foo", "bar", "Active", "image")inrevision/table_test.go)Listers(input state),WantXYZentries (output state) viaresources.MakeFoo(...)where the same helper method is used to supply the core resource again.addConfigLabel,mutateService, ...)I think this gets us the tersest expression of the table test that conveys what we want.