Microservices Architecture: Tools for a (Minimum) Quality Process

Everyone talks about digital transformation, about how APIs can connect your business in the information society, and the sky is the limit by incorporating all of this into a microservices architecture.

“APIs today, APIs tomorrow, APIs forever!”

However, in smaller proportions, we see suggestions to ensure quality across the various layers that exist in a microservices architecture. In this article, I will briefly mention tools we use in the project I work on to improve our quality processes.

Contextualizing Testing

The foundation for our strategy was the articles on Martin Fowler’s website, especially those focused on microservices architecture, which bring a new adaptation of the well-known Testing Pyramid.

More complete, right?

In this Pyramid:

• Unit tests test the smallest part of the software (that is testable) determining if the behavior is as expected, as we can read here.
• Integration tests verify interactions between internal and external components to detect any interface defects, which may involve a single component or several. We also have contract integration tests, which check if this contract meets what the consumer expects. Read more in this post.
• Component tests isolate components by replacing real interfaces with internal interfaces for testing, as explained in this topic.
• End-to-end tests (or Broad Stack Tests) verify if the system meets the requirements and achieves its objectives through end-to-end tests across the entire system.
• Exploratory tests are tests executed by a QA, manually exploring the system, looking for uncharted failures in other layers’ tests and better educating the already automated tests.

And how is our architecture?

Our architecture is a microservices architecture, but using the query language GraphQL to expose and redirect most of the data.

If you want to know a bit more about how GraphQL can be used in a project, I strongly recommend reading a great article from the Netflix team detailing the learnings from its adoption, and the folks at GetNinjas also did a great post explaining how it fits into this architecture.

Tools and Processes for Each Layer

Unit Tests

As we deal with microservices in Java, in an MVC architecture, we utilize the range of possibilities that Spring offers us, along with the tools it has for unit and integration testing.

Integration and Component Tests

For these tests, we are using the powerful Postman, created to test RESTful services, which can validate:

• Each integration through the testable interfaces in REST APIs and also through the calls of queries and mutations in the GraphQL engine.
• The complete functioning of each component, expecting that the response from the request is within the expected range.

Today, Postman does not natively support fetching the GraphQL schema like its simpler and trendier competitor, Insomnia. However, changes are emerging, and it is starting to give competitors sleepless nights.

End-to-End Tests

For these tests, we use the famous Cucumber, with its implementation in Javascript. Every use case written with BDD is passed to it.

However, with the growing number of use cases and the effort to maintain Cucumber, we are studying (and might use!) the simple and powerful Karate Framework, which combines “API test-automation, mocks and performance-testing into a single, unified framework,” creating a kind of DSL focused on HTTP, JSON, and XML — which is interesting for our scenario, especially with a very technical team. The folks at Hackernoon explain this better.

hopefully the use of Karate will really eliminate the bugs in the code!

However, in addition to REST and GraphQL APIs, the team I work with is also responsible for a web portal — and for automation with screens, nothing more classic than the mature Selenium. We are also starting to use Zalenium, which is scalable and allows parallel testing.

Exploratory Tests

Who usually looks for errors, explores the software component, and creates creative tests while navigating through non-obvious scenarios? The QA! Obviously, they will only do this if the other types of tests are being covered in other tools, due to time and patience issues as well — after all, nothing is more exhausting for the QA than to require them to execute only tests that could be elaborated and automated in other layers.

And our BDD?

For BDD, we adapted the Three-meeting-friendly process for documentation review, which involves:

1. The Product Owner, writing the functional documentation, where the requirements of a specific API/resource will be explained and mapped.
2. The Architect, writing the technical documentation with sequence diagrams and a good Swagger.
3. The QA, who will analyze these documents and write the BDDs.

We Encountered New Challenges in the Process

• We are currently building a QA environment so that tests can be executed separately from other environments (without overloading the dev environment).
• We still need to improve how to bring test reports and metrics into the daily lives of developers; ideas ranging from having a TV that displays the builds that broke (in tests) to having a “test manager” have emerged, but we are still aligning the best path.
• Performance testing has not yet entered our CI/CD and development process — another novelty that is on our roadmap!

Well, I would like to have shared with you a bit of what was needed to deal with quality processes for microservices architectures.

Thanks to Guilherme Machado Rogatto, who reminded me to mention Zelenium :)

I hope I have helped!

Best regards!

Post migrated from Medium.

• By Mai R. on May 24, 2019.
• Original Link