Study project about QA strategy for microservices projects

🗄️ Archive
, , ,
1

Hello guys,

In the last few months I started a personal study project. The initial objective was to further study the differences in the development and implementation of quality strategies for microservices with synchronous and asynchronous communication. I decided to do all the development of the application and the tests from scratch to be able to better observe some details in practice. I ended up doing a lot of things and the project grew a lot LOL

I am writing this post because I would love to receive feedbacks/code reviews of my code, strategy and any other details that can be helpful to the project or contribute with some knowledge. Feel free to give your opinion and criticize on any point. I will describe in more details some things that were done to give a better context:

The QA strategy involves:

  • Unit Tests: Junit5
  • Integration tests: Spring Boot Test and EmbeddedKafka (when testing asynchronous events)
  • Quality Metrics:
    • Mutation Tests / Mutation Coverage: PITest
    • Code Coverage: Jacoco
    • Technical Debt, Code Smells and other complementary metrics: Sonar Cloud
  • Contract tests: Pact framework
  • Continuous Integration: This project uses Github Action for Continuous Integration, where it executes all the tests and Sonar Cloud Analysis for every pull request, making easier the process of integration of every new code, also facilitating the process of Code Review.

The project also includes some extras such as docker compose configuration, pipelines configured in Github Actions, swagger configuration for each module, automated creation and upload of docker images to DockerHub, application of Code Style with spotless plugin. For more details, just take a look on the repository.

One thing that I was thinking about if would be necessary to include in this specific testing strategy, are the E2E tests, since in this context of my application, I have already managed to cover several different points with the other tests mentioned above. One type of problem that the E2E test would be able to identify in this context that others would not be able to, are infrastructure and configuration problems. For example, when I created Docker containers for each of the modules, I saw that they were not communicating properly due to possible problems with my DockerFile. This type of problem was only possible to identify with an E2E test. So the point I keep thinking about is whether it would be more efficient to have only some kind of health checks of infrastructure points like this, instead of creating an entire E2E test to identify details like this, or maybe this E2E test could still have a value as an acceptance test for the business, then it would still be better to create it. Note: It may be complicated to demonstrate it here, but I believe that talking about the coverage of the application itself, these E2E tests would only validate again some points already covered in the other tests.

Here is the link for the repository: GitHub - teixeira-fernando/EcommerceApp: QA Strategy for microservices with Synchronous and Asynchronous communication

Thanks in advance,

8 Likes
2

Complementing what I mentioned about the E2E tests above:

I tried to list which details could be identified in the E2E test, and not by the other tests, specifically for my context. I took as an example, the functionality to create a purchase order, where the “shop” module will perform a synchronous communication with the “inventory” module and an asynchronous communication with the “shipment” module.

  • Timeout in synchronous communication;
  • Inventory module is not running when creating the order;
  • Problem creating the topic in the Kafka queue;
  • Communication / configuration problems between the modules’ containers;

I see that the second and fourth points could be solved with a health check and more monitoring resources of the application. The third point also I imagine that we can have health check from the queue to ensure that there will be no failure at that point;

The first point (could be related to network fluctuations), could be partially solved with some retry policies and retry polling for this synchronous communication.

I also think that if I had an API gateway that intermediated all the direct communication to the modules, we could have an extra value with a possible E2E test (Another point of possible configuration and infrastructure problem);

My question is: Is there any other problem that the E2E test could identify that I did not listed there? Speaking specifically only of this context of my application, where we already have unit tests, integration and contract already well structured

3 Likes