Add tests for flux trace command

[allenporter]

Add tests for flux trace command that fake out the kubernetes client,
load objects from a yaml file and create them in the client, and
assert on the output of the trace command to an expected golden file.

Follow up from the suggestions in PR #1626 which suggested that additional
testing would be helpful. This test approach is modeled after the helm command tests.

This required some changes to the kubernetes client setup to make it possible to use a fake. If we agree this pattern makes sense, it can be applied to other commands (kube client creation, and test library setup could be moved to a common place). An alternative could be to use envtest which seemed much more heavyweight. Another alternative could be to declare all the objects in go code instead of in yaml.

To set your expectations: I'm new to go, flux, and k8s libraries so am not familiar with many existing conventions, but very happy to adjust as needed.

Ref: #1603

[stefanprodan]

This looks great! @allenporter can you please move the test files inside testdata/trace, this way we'll have a dir per command. Thanks

[stefanprodan]

@allenporter can you rebase with main, squash both commits and signoff your commit please.

[allenporter]

I see you also recommended following this pattern for the e2e tests too which is cool.

As I am thinking about adding coverage of more commands, wanted to share my early thoughts. In particular, just want to make sure this is easy to maintain:

• Will it be easy to detect bugs in yaml object files? Seems worth it for now, but not sure how this plays out
• Will maintaining the yaml files require lots of small changes across many files as new fields are added?
• Should simple test cases just inline the errors instead of using a golden output? (e.g. "object kind is required (--kind)", "object apiVersion is required (--api-version", etc). I lean towards yes.

[stefanprodan]

Will it be easy to detect bugs in yaml object files?

We could use kubeval along with the Flux API specs to validate the inputs, e.g. https://github.com/fluxcd/flux2-kustomize-helm-example/blob/main/scripts/validate.sh

Will maintaining the yaml files require lots of small changes across many files as new fields are added?

It depends on the test case, Flux APIs are stable, that means all new fields are either optional or have defaults. When adding a new field to a CRD, if that field is also added to the CLI create command, then yes, the golden file should be updated.

Should simple test cases just inline the errors instead of using a golden output? (e.g. "object kind is required (--kind)", "object apiVersion is required (--api-version", etc). I lean towards yes.

Yes I agree, no point in creating tones of one-line golden files. I think golden files should be used for when the output is a table view or a list view.

[stefanprodan]

LGTM

Thanks @allenporter 🥇

[stefanprodan]

@allenporter FYI #1682