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!

  • Where does the UI live? Is it a monolithic UI? May 21, 2019 at 14:53
  • No, we have a website and a mobile app that uses the same API.
    – resmall
    May 21, 2019 at 16:32
  • Not sure what you mean with a project, but I mean is the UI in a single project or separate code repository? Lets say one for the website and one for mobile app. Or does the front-end also have multiple projects? If it is a single project then it is a sort of monolithic UI on top of microservices. If so the end-to-end user acceptance tests could live with the UI, as the acceptance tests probably use the UI to test multiple services in a single flow. If the front-end is also split in functional projects then maybe a new high level project would be the solution. May 21, 2019 at 17:01
  • By project I mean repository. The UI is a separate code repository. One for the mobile app and another for the website.
    – resmall
    May 21, 2019 at 17:47
  • 1
    Please update your question with the information about the way the code is spread across different repositories
    – Kate Paulk
    May 21, 2019 at 19:20

1 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.

  • Another way to look at this problem is to consider integrated microservices as a system... which would require system tests. Web & mobile should also have their own respective test layers that live with those projects, but don't necessarily test things outside the scope of those projects. (Do you really want to test the back-end as part of front-end testing?) Contract testing tools like Pact.io have emerged to plug the gap, as well. May 24, 2019 at 0:02

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.