I have to integrate API test-automation on a project that has a microservice architecture. Each back-end service has a different repository and is deployed separately. I haven't had the opportunity of implementing test-automation on a microservice architecture before, therefore I am not sure how to approach setting up the test data.

Let me introduce you to my dilemma: let's say we have a service called Categories and a service called Subjects, both services have create and delete operations, each with its own API endpoint. But here is the pickle, in order to create a Subject using the Subjects service, a Category already has to exist, in order to be selected. But since a microservice architecture is in place, I don't have access to the Categories API endpoints in the Subjects service, so I cannot create a Category while the tests for the Subjects service run in the Subjects repo, which leads to my question: what approach should I opt for in order to provide the required-dependent test data?

  • How does Subjects knows which Categories are in place? Is it through an API between the services ?
    – Rsf
    Commented Mar 2, 2020 at 10:10

1 Answer 1


Depending on how those microservices interact with each other there may be several possibilities. The whole microservices concept was created to allow microservices to be developed/tested/deployed independently.

That means, in an ideal world, microservices would interact using some kind of contract and API. Usually (almost as de-facto standard), microservices would communicate using REST API. If this is the case, instead of creating an entity in Categories, you would mock Categories using solutions, such as Wilma or WireMock.

The Test Stand diagram may look like this:

+-------------+  Get Category Entity API +----------+
| Categories  |<-------------------------| Subjects |
|   Mock      |------------------------->|  Service |
+-------------+                          +----------+ 
                                              || Category dependent call
                                       | Test Client |

To the best of my knowledge, this is the way system-level testing for a single service in microservices architecture is meant to be organized.

We're not always live in an ideal world. Sometimes, the real dependency diagram would look like this:

+-------------+             +----------+
| Categories  |             | Subjects |
|   Service   |             |  Service |
+-------------+             +----------+ 
       |                          |
       |                          |
       |       +----------+       |
       +------>| Database |<------+

This may be an architecture flaw or a conscious decision to use database as an API.

In this case, your options are limited to:

  1. Getting access to the Categories service and creating a test entity using it, or
  2. Writing to Database directly

It is hard to tell which option is preferred because the choice would depend on many factors.

  • When a Subject is created, the back-end checks to see if the Category that the Subject was assigned to exists in the DB, therefore I guess that the Wilma / WireMock solution won't work here. Commented Mar 2, 2020 at 11:12
  • 3
    @GeorgeCernat If this is the case I would strongly suggest to clarify if it is a design flaw or conscious decision. If it is the first - fix it, then go with mocking. If not - your choice has been made for you. Commented Mar 2, 2020 at 13:32
  • Thanks for a great answer! Commented Mar 2, 2020 at 13:33
  • @GeorgeCernat if the 'service' is accessing the database directly, then you could add mock category entries directly to the database as test setup and then verify that its being removed after delete call right ? whats the challenge in this approach ? Thanks for this questio and Alexander for the detailed answer
    – PDHide
    Commented Mar 2, 2020 at 14:12

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.