Helm Test best practices
Just starting this topic:
In my opinion it depends on your needs.
For the 1,2,3 - as I understood "helm test" is very flexible and it can perform any additional tests depends on your needs.
You can use different images and different approaches or one image with different arguments but sometimes probably it can be impossible due to docker entrypoint - please see commands and arguments.
According to the 4 question - in my opinion you should consider using configmaps and secrets to define and expose env variables into your pods.
Additional resources "helm test":
- Integration testing deployed services using “helm test”
- How to use helm chart test to do integration tests?
Hope this help.
an example you can find in mysql chart by the following link https://github.com/helm/charts/tree/master/stable/mysql/templates
Answering my own question:
- We made a separate docker image for helm tests due to the following reasons:
1.1 When helm smoke docker image is separate that makes it free of any constraints of the main app docker image. So you can install any libraries and avoid following some security guidelines that main app has to follow.
1.2 There is no restriction on the size of a docker image for helm test becasue it is short living image , the image of helm test is a live for a duration of tests inside. - We marry them via Chart version. So the image of main application has always the same version as the helm tests docker image.
We don't have to pass anything, when you run "helm test yourapp", helm looks for successfully deployed version of yourapp and runs helm test with that version.
3. When you run the "helm test yourapp" command. Helm looks in file
yourapp/templates/tests/smoke-test.yaml
calls command that is specified by the following path:
spec/containers/command: ["sh", "-c", "your command"]
plz have a look on the screenshot or go to git repo of mysql chart https://github.com/helm/charts/tree/master/stable/mysql/templates 
- The best way to pass data and Env specific data is passing them via config maps, env variables, and secrets as Hanx unanswered. If it is stored in such a way then you can populate such data via helm values files and it will be easy to update. We found that having env specific data inside image is a bad solution because if for example a URL/host changes in some environment we need to create a new build instead of just updating a values file and performing deploy.