Improve Ginkgo/Gomega Test Practices in Scaffolded and e2e Tests

[camilamacedo86]

What do you want to happen?

Kubebuilder creates/scaffolds a lot of test code. This test code uses Ginkgo and Gomega. Some of the tests as written don't take full advantage of Gomega's testing framework. Since Kubebuilder is likely to introduce many developers to Gomega, it is important that the scaffolded code provides the best possible examples.

We should see that the tests scaffolded for end-users have this issue fixed already: testdata/project-v4/test.

What we need to do here is ensure that ALL our e2e tests are also following the same patterns as the end-user scaffolds. Therefore, the necessary changes must be implemented in: test/e2e.

Context

The context for this issue and similar discussions can be found here: kubernetes-sigs/kubebuilder#4135.

Tasks

1. Review and compare the test scaffolds in testdata/project-v4/test to ensure best practices in Ginkgo/Gomega are being followed.
2. Update all e2e tests in test/e2e to align with these patterns and provide the best examples for developers.
3. Validate that the tests maintain readability while leveraging Gomega's framework effectively.

Extra Labels

/kind cleanup

[Sijoma]

/assign

[mogsie]

In #4135, I originally made a suggestion of replacing the following type of tests:

result, err := someFunc(param, param)
Expect(err).NotTo(HaveOccurred())
Expect(result).To(ContainSubstring("blah"))

with the more concise (but functionally equivalent)

Expect(someFunc(param, param)).To(ContainSubstring("blah"))

The one line above

• checks that err is nil
• and that the resullt of the function call matches the matcher.

Should we reconsider this? The one line is (to me) more maintainable, although it relies Gomega implicitly testing that err == nil of the last return value.

From #4135:

... this has been decided against, as it hides the number of return values, which makes it harder to learn the API being tested. The desire is therefore to keep the three-line version, instead of in-lining it.

Maybe we should provide a document that describes the desired test idioms for the scaffolded tests and for the internal tests? Because, as mentioned, kubebuilder will often be introducing both Ginkgo and Gomega to its users; we should probably spend time explaining some of those test idioms in the scaffolded tests.

e.g. adding a comment as denoted by /**/ below:

	BeforeAll(func() {
		By("creating manager namespace")
		cmd := exec.Command("kubectl", "create", "ns", namespace)
		_, err := utils.Run(cmd)
		Expect(err).NotTo(HaveOccurred(), "Failed to create namespace")

		By("labeling the namespace to enforce the restricted security policy")
		cmd = exec.Command("kubectl", "label", "--overwrite", "ns", namespace,
			"pod-security.kubernetes.io/enforce=restricted")
/**/		// Expect(...).Error() allows us to make assertions about any errors
/**/		Expect(utils.Run(cmd)).Error().NotTo(HaveOccurred(), "Failed to label namespace with restricted policy")

This way we would be "teaching" the API (in this case the utils.Run(), and then how to use Ginkgo to make assertions against that.