Acceptance tests in microservices: should they be inside the project or separated

Question

Currently we have 15+ microservices separated in their own repository and each one of them holds their unitary and integration tests, which are run when a new commit is made.

We also have two clients that use our microservices, a website and a mobile app. Each one of them in their own repository.

At the moment we do not have any acceptance tests.

Then the following question came to my mind: if I release a new version of our user service, all its corresponding unitary and integration tests will be run (create, update, remove and the like).

Now I want to have our acceptance tests run, let's say I want my user to successfully place an order, the steps would be somewhat as follows:

• Create user
• Authenticate
• Place order
• Process payment
• Order placed
• (Happy user)

Those tests must reside within the users repository or should I create an entirely independent repository that executes those steps everytime a new commit is made, to any of my services?

For instance, let's say I make a new commit to coupon service, the test I mentioned before wouldn't be run, but then I could have broken something that only the acceptance tests in the customer service would have caught, this is why I'm thinking I should have one separate repository, call it a AcceptanceTestProject, containing all these acceptance tests (or at least the most important ones) that would be run everytime a commit would be made.

Currently I think I should have this separate repository only with acceptance tests as part of my pipeline, so it would be run, no matter what microservice is being updated.

But please correct my thought if I'm missing something.

The pipeline would be something like:

1. commit
2. unit tests(user service)
3. integration tests(user service)
4. acceptance tests (separate application)
5. integrate

Thank you!

Answer 1

I like to keep the acceptance tests as close to the code as possible.

If your acceptance tests test from a user perspective I would locate them in the code repository of the website or mobile app.

If the same acceptance tests are used by both the website and the mobile app you could opt for creating a separate repository, but I think I would rather duplicate the tests as the two platforms might diverge in the future. My experience is that mobile apps are often slimmed down version of the website version, having slightly different user flows. Also the used testing framework (or workarounds/hacks) will differ between web and mobile.

Still always wonder what is the simplest thing that could possibly work. Try it, inspect and adapt.