This follows the best practice based on my experience maintaining Helm charts and testing as much as possible before deploying the chart to local and remote clusters. Snapshot testing is handy because it runs quite fast and is perfect for detecting any unexpected changes.
Once this is merged, maintainers and contributors are encouraged to add a few lines to tests/surrealdb_test.go when they add control structures like if and range to the templates so that branching is tested and future regressions can be prevented.
terratest: because the only things we can leverage from it are some helm helpers, which can be easily implemented in one Go file without introducing another Go package dependency that we need to maintain.
helm-unittest: because I want catch-all snapshot tests rather than writing every single test case ourselves. We have limited bandwidth.
helm-test: because it's more like an integration or e2e testing framework that deploys the chart to a cluster and sees if the test pod succeeds = slower than snapshot/unit testing and tests different things.
Those tools are great. I'm just proposing to use the one that is sufficient and enough for this specific project today, and that's plain Go!
Lastly, this is about detecting unexpected changes. Verifying whether expected changes work is another story beyond the scope of unit (and template) testing.
Let me add unit tests written in plain Go to catch templating issues like the one found at https://github.com/surrealdb/helm-charts/pull/9#pullrequestreview-2368588011.
This follows the best practice based on my experience maintaining Helm charts and testing as much as possible before deploying the chart to local and remote clusters. Snapshot testing is handy because it runs quite fast and is perfect for detecting any unexpected changes.
Once this is merged, maintainers and contributors are encouraged to add a few lines to
tests/surrealdb_test.gowhen they add control structures likeifandrangeto the templates so that branching is tested and future regressions can be prevented.I opted not to use:
Those tools are great. I'm just proposing to use the one that is sufficient and enough for this specific project today, and that's plain Go!
Lastly, this is about detecting unexpected changes. Verifying whether expected changes work is another story beyond the scope of unit (and template) testing.