Test IncludeGenerated

[genevieveluyt]

Description

Adds a test for #374

Additionally:

• The service.yml ClusterIP was invalid ("The Service "test-service" is invalid: spec.clusterIP: Invalid value: "10.0.171.239": provided IP is not in the valid range. The range of valid IPs is 10.96.0.0/16")
• Importing the test package in client_test.go caused a circular dependency so updated the package from k8sinternal to k8sinternal_test

Type of change

• Bug fix 🐛
• New feature ✨
• This change requires a documentation update 📖
• Breaking changes ⚠️

How Has This Been Tested?

• Test A
• Test B

Checklist:

• I have 🎩 my changes (A 🎩 specifically includes pulling down changes, setting them up, and manually testing the changed features and potential side effects to make sure nothing is broken)
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• The test coverage did not decrease
• I have signed the appropriate Contributor License Agreement

[genevieveluyt]

The service.yml ClusterIP was invalid ("The Service "test-service" is invalid: spec.clusterIP: Invalid value: "10.0.171.239": provided IP is not in the valid range. The range of valid IPs is 10.96.0.0/16").

This doesn't affect tests or anything. I just happened to try to kubectl apply the service into a kind cluster and it failed.

[rxbchen]

Thanks for catching that!

[alexhope61]

Is this the normal convention that the package test have a different name than the package itself? I've not done this before and I'm wondering if I should have been...

[rxbchen]

I remember is something to do with blackbox/whitebox testing 💭. I think when we call this a different name, we would have to import k8sinternal in order to get access to the rest of the code.

[genevieveluyt]

Exactly what Brian said! It depends what you want to test.

If you use the same package as the code you're testing (whitebox), you have access to the private methods in the package and can test those.

If you use the special _test package (normally Go won't let you have multiple package names in the same directory, so appending _test to the package is a special case), you can test your code as if you were a consumer of the package (blackbox).

In this case we're not testing any private methods so using the "test" package is kind of a cheat to get out of import cycle problems. Alternatively we could move the functions that cause the import cycle into a new package and import that from both k8sinternal and test.

[alexhope61]

TYVM for the explainer!

[rxbchen]

Looks good!

[rxbchen]

I remember is something to do with blackbox/whitebox testing 💭. I think when we call this a different name, we would have to import k8sinternal in order to get access to the rest of the code.

[rxbchen]

Thanks for catching that!