This content originally appeared on Bits and Pieces - Medium and was authored by itay zohar
Part 1: Overcoming the challenge of testing in multicomponent architecture.
Multicomponent architecture is trending in recent years. But together with the ease in planning and pivoting, it brings a challenge to testing.
To me, there are two basic approaches to solving this challenge:
- E2E orchestration, or “the old way”.
- Contract testing, or “the new way”.
The Old Way: E2E Orchestration
In this approach, we will basically try to create a classic “E2E system test”. An attempt of executing our core business scenarios throughout our complex environment.
Why Choose This Approach
If the organization has a handful of highly important operations, the include a lot of software components — E2E could be the right choice.
While this kind of E2E test requires complicated planning, it should be faster to build.
How to build E2E orchestration
- Understanding our scenario
Business-wise: Define what this scenario is, what is the flow? why is it important? what are the risks in the case of bugs?
Technical-wise: how it is implemented, what are the components involved? Make sure you have a clear architecture design. - Describe what should be done. High level
Here we plan our test scenarios. for example, “service A sends this kind of request to service B, which then saves it to a file processed by service C” - separate test logic from component logic.
Create an automation project for each component in the environment, implementing the component's functionality related to our scenarios.
second, create a test scenarios component, containing test scripts that use each component project to create needed test steps.
We will call this “test scenarios project”: the conductor (which means “the orchestrator”).
The New Way: Contract Testing
Contract testing is the new cool kid on the block. While E2E gazes at an Organization-wide process. Contract testing focuses on the integration of every two components (AKA contract) separately.
The idea is that maintaining these “contract definitions” is all you need, as long as you keep the contract up to date between every two components in your system.
To understand why, Let us say that our organization contains three dev` teams that work on three components: service A, service B, and Service C.
- Each team defines a contract (most of the time — API definition and stubs), and the contract is a way for *other teams* to test their integrations.
- Each team, independently, performs full system tests: regular component tests + contract integration tests.
- The whole E2E architecture is now safe.
Let’s dive a little deeper to understand the advantages here
Let’s say Service A serves information to service B.
So service A will define a contract and share it with service B.
Now, B can handle its integration testing independently, without the need for team A to be involved.
If this process is implemented for every integration, it means team B can be in charge of the entire service B testability.
That is a big deal: without contract testing, each service can be in charge of its own processes, but integration is often left out, orphaned, as it Has no clear or easy way to test. This neglection is exactly what causes organizations to invest in long, complex E2E tests.
But it’s not so simple (yet)
Sadly, from the frameworks I tried, This approach is not yet fully developed. contracts get broken so easily — that the difference between “contract testing” and good old integration tests is shrinking dramatically.
Conclusion
Multicomponent architecture is becoming increasingly popular, but it brings new challenges to software testing. E2E orchestration and contract testing are two common approaches to testing in this context.
If there will be a demand — I will write a deep dive into each of these techniques to help you understand exactly how to implement them in your organization.
Build Apps with reusable components, just like Lego
Bit’s open-source tool help 250,000+ devs to build apps with components.
Turn any UI, feature, or page into a reusable component — and share it across your applications. It’s easier to collaborate and build faster.
Split apps into components to make app development easier, and enjoy the best experience for the workflows you want:
→ Micro-Frontends
→ Design System
→ Code-Sharing and reuse
→ Monorepo
Learn more:
- How We Build Micro Frontends
- How we Build a Component Design System
- How to reuse React components across your projects
- 5 Ways to Build a React Monorepo
- How to Create a Composable React App with Bit
Test Automation of Large Scale Integration: Architecture Overview was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Bits and Pieces - Medium and was authored by itay zohar
itay zohar | Sciencx (2023-02-22T07:10:45+00:00) Test Automation of Large Scale Integration: Architecture Overview. Retrieved from https://www.scien.cx/2023/02/22/test-automation-of-large-scale-integration-architecture-overview/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.