How to approach setting up test data for a project that has a microservice architecture?

Question

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?

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
                                              |v
                                       +-------------+
                                       | 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.