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

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.

No comments :

Post a Comment

Leave A Comment...