we are currently setting up a GitOps-Workflow. What I'm wondering is how to include our e2e-tests best. As I would like to make sure, that the whole application runs flawlessly before allowing a merge-request to be approved the tests should run for every MR in the GitOps-Repository. But where would the e2e-tests live then? My gut-feeling is to add the e2e-tests to the GitOps-Repository as well, so that I only have one single MR if I want to change my deployment and have to add/modify the corresponding e2e-tests. But maybe there is a better solution? All I want to avoid is to have multiple MR in different repositories (one MR for e2e-tests and another one for GitOps), which have to play together or have to be executed/merged in a defined order. How did you solve this challenge?
2 Answers
My personal preference is to put the tests near the code that it's testing. However, since E2E are testing different pieces of software which I assume are separated in different repos in your organization, it doesn't make sense to scatter these tests throughout the repos. I see that you have a repo called "GitOps repo" which seems like it's responsible for some parts of CI/CD or infra right ? I think you can put the E2E there.
If you are using Kubernetes, you can check [testkube][1] which allows you to store and deploy your End-to-end Tests easily in your environments. [1]: https://testkube.kubeshop.io/
E2E tests are the most expensive tests to do and running E2E tests on every merge request is not recommended and seems to be an overkill.
Requirement to run E2E with every merge indicates fundamental problem.
Integration tests and E2E should be in later stages in the pipeline but before "promotion for release" stage.
- 685
- 1
- 8
- 12