feat(test): use builder to build test objects.

[jvanz]

Description

Creates builders to allow dynamic object building during tests.

Part of #824

@kubewarden/kubewarden-developers this is one of a series of PR open to refactor the webhooks tests. This is a initial change to use builder pattern to build (hehe) test objects. This is not a 100% convertion. But it's a start to see if you are all fine with the current changes before the next one following the same idea.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.35%. Comparing base (7110ea8) to head (f17d163).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #955      +/-   ##
==========================================
- Coverage   67.51%   67.35%   -0.16%     
==========================================
  Files          30       30              
  Lines        3128     3128              
==========================================
- Hits         2112     2107       -5     
- Misses        848      852       +4     
- Partials      168      169       +1     

Flag	Coverage Δ
integration-tests	56.59% <ø> (-0.17%)	⬇️
unit-tests	40.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fabriziosestito]

@jvanz this looks great, few comments below:

• We could name the builders "factory"; this naming is commonly used in tests to describe generated test data (as opposed to fixtures). See for example https://github.com/beam-community/ex_machina
• Reference link: We already use a factory for other objects, but we are not applying the builder pattern. It would be good to migrate to it.
• It would be nice to place these in a separate file (e.g., factories_test.go).

[jvanz]

@kubewarden/kubewarden-developers I've rewrite all the factories function from the internal/controller/utils_test.go. Let me know what do you think.

right after pushing the code I had another idea. Which is using a factory method with variable argument to define the objects configuration. For example:

admissionPolicyFactory(withName("foo"), withPolicyServer("default"))
// or
admissionPolicyFactory(withName("foo"), withPolicyServer("default"), withMutating(true))

Something similar to what other go projects do to customize configuration. But I'm not sure what do you prefer. I do have have any string preference on either options. I just want to share all the paths with you.

---

Another thing, I'm not migrating the factories from the api/policies/v1/policy_utils_test.go file because I'm planning to do the validation of the webhook in the integration tests as described in the acceptance criteria of the issue #824

[fabriziosestito]

admissionPolicyFactory(withName("foo"), withPolicyServer("default"))
// or
admissionPolicyFactory(withName("foo"), withPolicyServer("default"), withMutating(true))

I think that what we have now is clearer than functional options

[flavio]

LGTM, thanks for the changes