How to organize integration tests in a microservice application?

Question

Software testing

There is a microservice application with a certain zoo of technologies (3 API applications, a frontend for the public part, a frontend admin panel).
All API applications are covered by unit and integration tests. We were given the task of organizing testing through UI tests in the browser emulator on important application screens. With testing technology stacks, I settled on a combination of WebdriverIO and Mocha. Covered one screen with tests.
The question arose: how to organize comfortable work with tests for front-end developers?
In mode:

• We were given the task of writing tests for such and such a screen. Wrote tests, ran them locally, made sure everything was green, made a pull-request.
  
• We were given the task of adding functionality to the screen. I wrote a functional, ran ready-made tests for this screen, made sure that everything is green, made a pull-request.
  

Questions in order:

1. Environment: When developing a front, the front uses a prepared API on a remote machine. It is convenient to work with him, since there is already a lot of data with which he can work and manipulate them. When running tests, I want to use a separate environment containing a minimum set of data, which would roll back to its original state after passing the tests. There is an idea to use a docker container for this, but I want to know how it is organized by others
   
2. Running tests: the developer should be able to comfortably run tests, literally with one command in the console. Therefore, I want to know where to store such tests (in a repository with a front or in a separate one) and how to deploy the environment correctly / more conveniently before launch?
   
3. Run frequency and CI integration: How often should these types of tests (when the whole structure is involved) be run? Every time one of the repositories is updated; every time you update the repository with the front; before release?
   

Answer 1

You make a docker-compose file in which you raise containers with all the necessary services (DB, API, ..., selenium / whatever).
You make a container that mounts a folder with tests into itself and runs them.
Then the tests will be launched, roughly speaking, with one command docker-compose up % service_name%
In CI, this can be launched in the same way (at least in travis / jenkins)
About storage - it’s most logical to keep this is in a separate turnip, if the front and different APIs are in different repositories, these are not front tests.