Cleanup go unit tests

[mengqiy]

There are some go unit tests in kubebuilder to test the generated files match expected.
Given that we have the golden files test, we can cleanup our go unit tests.
We can probably only keep the tests for testing the scaffolding machinery, but not for each generated file.
Maintaining go unit tests requires more efforts than the golden test, since whenever a new file is added or a file is deleted, we need to change the go test to reflect it.

2 actionable items:

• remove go unit tests for scaffolding files
• ensure enough coverage for the scaffolding machinery

[camilamacedo86]

HI @mengqiy,

The golden tests are e2e tests and have not the same purpose as the unit tests. See that the golden will not cover all scenarios cases as the unit does. IHMO they have different purposes and both should be kept. Also, unit tests are faster and allow us to check, debug and ensure specific points locally which is very helpful for the development purpose. And then, in POV we should add more unit tests instead of just keep the golden one.

Wdyt? Is it make sense?

[Adirio]

I think the name of unit tests brings a bit of confussion because they were really like e2e tests disguised as unit tests. They were basically creating a file in memory and checking it against the testdata folder. They were probably left-over code from before golden test was being used for this purpose. The discussion me and @mengqiy were having that brought up his issue was that these disguised tests were overlapping with the golden test and were way harder to maintain as new files required to write additional tests, where the golden test will already understand new files without requiring changes to the tests.

[camilamacedo86]

Hi @Adirio,

Thank you for the clarification. I checked the tests removed at #1343 and they are like the same e2e done in the golden tests as you said. So, for one side make since removing the duplication in order to ensure the changes performed.

However, IMHO would be great we cover the project with unit tests at least since they will allow covering more scenarios cases. Also, tests implementing using go are faster and allow us to check, debug and ensure specific points locally which is very helpful for the development purpose which indeed I would advocate in prol of the usage of go test framework instead of third-party APIs as well.

May we can work on this after. Really thank you for your fantastic contributions 🥇

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.