chore: adapt Makefile command to run unit tests

[odubajDT]

No description provided.

[netlify]

✅ Deploy Preview for keptn-lifecycle-toolkit ready!

Name	Link
🔨 Latest commit	f3cc13c
🔍 Latest deploy log	https://app.netlify.com/sites/keptn-lifecycle-toolkit/deploys/64fecf7e30f10c0008f8e211
😎 Deploy Preview	https://deploy-preview-2072--keptn-lifecycle-toolkit.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[codecov]

Codecov Report

Merging #2072 (b92529d) into main (bd15001) will decrease coverage by 24.84%.
The diff coverage is n/a.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #2072       +/-   ##
===========================================
- Coverage   83.98%   59.14%   -24.84%     
===========================================
  Files         150       35      -115     
  Lines        9597     2389     -7208     
===========================================
- Hits         8060     1413     -6647     
+ Misses       1246      836      -410     
+ Partials      291      140      -151     

see 127 files with indirect coverage changes

Flag	Coverage Δ
certificate-operator	68.55% <ø> (ø)
lifecycle-operator	?
metrics-operator	?
scheduler	32.12% <ø> (ø)

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

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[thisthat]

I would not introduce this change since they could be anything and not necessary just unit tests. At the end, the current entry is a wrapper around go test, hence make test is a better name imho.
If you'd like to have a "run local tests before creating a PR", I'd rather have a new Makefile entry in the root Makefile with a unit-test step that calls all the test entrypoint in the respective sub-folders.

[odubajDT]

I would not introduce this change since they could be anything and not necessary just unit tests. At the end, the current entry is a wrapper around go test, hence make test is a better name imho. If you'd like to have a "run local tests before creating a PR", I'd rather have a new Makefile entry in the root Makefile with a unit-test step that calls all the test entrypoint in the respective sub-folders.

I would argue here. Currently make test runs only unit tests, but for me as a user it sounds like it runs all the tests (what is not true). We also use make test command as part of unit-tests pipeline, which speaks for itself. I think this was just named wrongly in the past. If we look at it from a higher perspective (for example for lifecycle-operator) we have multiple makefile entries:

• component-test
• e2e-test
• integration-test
• test (original name, in this PR rename to unit-test)

This for me makes logical sense.

About the second though of introducing a unit-test entry in the root Makefile -> I would be against this. In most cases, developers are adapting only one component of the toolkit (at least this should be true for the majority of PRs), so metrics-operator, lifecycle-operator, ... It does not make any sense to have the possibility to run unit tests for all components, when you are adapting only a single one. For advanced tests (like integration-tests) it surely does, but for simple unit-tests not.

[RealAnna]

I would not introduce this change since they could be anything and not necessary just unit tests. At the end, the current entry is a wrapper around go test, hence make test is a better name imho. If you'd like to have a "run local tests before creating a PR", I'd rather have a new Makefile entry in the root Makefile with a unit-test step that calls all the test entrypoint in the respective sub-folders.

I would argue here. Currently make test runs only unit tests, but for me as a user it sounds like it runs all the tests (what is not true). We also use make test command as part of unit-tests pipeline, which speaks for itself. I think this was just named wrongly in the past. If we look at it from a higher perspective (for example for lifecycle-operator) we have multiple makefile entries:

• component-test
• e2e-test
• integration-test
• test (original name, in this PR rename to unit-test)

This for me makes logical sense.

About the second though of introducing a unit-test entry in the root Makefile -> I would be against this. In most cases, developers are adapting only one component of the toolkit (at least this should be true for the majority of PRs), so metrics-operator, lifecycle-operator, ... It does not make any sense to have the possibility to run unit tests for all components, when you are adapting only a single one. For advanced tests (like integration-tests) it surely does, but for simple unit-tests not.

Also OFO does use unit-test https://github.com/open-feature/open-feature-operator/blob/main/Makefile and same goes for prometheus operator where test calls all tests including unit-tests https://github.com/prometheus-operator/prometheus-operator/blob/main/Makefile#L338

stale