4

We have separate repos for the backend and the front end. The backend which is just microservices has its unit tests(jest), microservice integration tests(jest), and microservice end-to-end tests(jest).

The front-end has the unit tests(jest) and application end-to-end tests(cypress).

Now, when there is a release for a specific microservice, I am guessing we should still ideally be running application end-to-end tests in addition to the tests from the backend repository. Given we are planning to write them in the front-end repository, what's the right way to go about it?

Given that the front-end and back-end are in separate repositories, we have separate CI/CD pipelines for both.

  1. Should Application end-to-end tests have a repository of their own (I do not think that is the right way) Or
  2. we should configure our CI/CD pipeline to pull code from the front-end repository as well when deploying the backend to run the application end-to-end tests. or any other recommendations?
Improve this question

2 Answers 2

Reset to default
1

https://sqa.stackexchange.com/a/43001/40022

When to choose different branch or repo

If you are deploying the test scripts to a different test server to execute the steps and is executed completely independent of the source code or minimal dependency. Then it doesn't matter where you keep your code. I would suggest adding the test scripts and the required dependency together and store it under a separate branch or repo as it will ensure that we don't confuse developers with our commits and files.

When to choose, merging to master branch of SUT source code

If test is executed as a build test step in package.json or maven then add it under the same repo and branch as the product getting deployed.

And to add to your question about two different pipeline , i am not sure why thats the way you have implemented .

You can have scripted pipeline where you clone the code and run the test for a particular stage. or you can separate frontend and backend projects that get triggered aumatically once the deployment is successful

Improve this answer
1

release for a specific microservice, I am guessing we should still ideally be running application end-to-end tests in addition to the tests from the backend repository

Why? The service has checks that validate its behavior (acceptance and unit checks) and that it can be integrated with its consumers (contract checks (for instance, with Pact).

enter image description here

If those are comprehensive and serve to validate this service when they pass, you deploy it (since you are implementing Continous Deployment), so people can test and use it.

You can use full system acceptance tests (E2E as you said) as a monitoring tool, in a test environment where external dependencies (e.g. credit card providers) are not stubbed out (which probably you are doing on the service level acceptance tests). Just keep them running continuously and triggering alerts about the health of that environment when some of them fail.

This environment probably will be one of the lasts stages before you go to production. So you can use your comprehensive set of full system acceptance tests as a way to validate if the current state of all services + UI can be sent to production.

Improve this answer
2
  • Thanks. Should application end-to-end tests(runs in the browser, uses cypress) be stored with the front-end repository at all or just in a separate repository? @João Farias
    – systemdebt
    Commented Jun 16, 2021 at 18:33
  • I would suggest go in the way that makes setting it up simpler. Modern SVC systems make very simple to coordinate integration.
    – João Farias
    Commented Jun 16, 2021 at 19:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.