Are we overcomplicating micro-frontend testing

A lot of my time was recently spent on researching the quality strategy for micro-frontend architecture. Our team is trying to expose one of our React components to other teams for reusablility and faster deployment. We thought Webpack Module Federation would fit our demand.

This obviously brings some challenges as well. Everyone in our team, though we are excited to move forward, has no prior experience in this. One thing which bothers us is how we can keep our confidence of updating our code without breaking others. Different from publishing a NPM package, where the integration responsibility falls on the consumer side. If a breaking change is introduced, they should update their code to adapt, or choose not to update. We can technically keep this mode for micro-frontend, but that is not our purpose to change. As we wish for faster release, we really want to leverage the benefit of deploying once (which is us the provider) and being effective everywhere.

We started looking out for contract testing for UI component. Contract testing is a norm for microservice. If we follow the paradigm of consumer driven contract testing, consumers should provide pacts to the provider, and whenever the provider introduces breaking changes, they will be notified. Then preventive actions will be done in the early phase. Similarly, I imagine there could be similar thing for micro-frontend, but after a long ploughing on Google, I surprisingly found there is no such a thing like Pact to do contract testing for UI component. I did find a GitHub issue showing that Pact is interested in supporting this feature, but it’s far not yet started.

Then I asked other people’s experience in Thoughtworks. Someone told me that contract per se is just a JSON definition of API calling, for UI component, it would just be the interface. We can manually write them in a JS file and share them through some artifact repository. I do doubt the effectiveness of this method due to the management and maintenance overhead. Someone told me that he was actually looking for something like this a couple of years ago as well to understand what states are actually used in a gigantic and chaotic Redux store. He asked me to let him know if I found anything because he didn’t when he tried. I was quite puzzled because Webpack Module Federation is not something completely new. How has people been using it in the industry?

Another view I saw is also quite interesting. They believe the unit tests of each individual micro-frontend and the E2E test on the whole should be sufficient enough. If breaking changes are introduced, the E2E test should be able to catch it, and we will catch it from the lower environment to the higher, so it wouldn’t be a problem. I am still thinking about this. It doesn’t sound so right to me because the feedback loop seems to be pretty long. If we only catch the issue in the whole E2E phase, chances are that a lot of rework will be required, and that is exactly what I was concerned from the first place.

TypeScript is also suggested to mitigate this issue. This is what I specifically pondered if we are overcomplicating the issue. If types and required properties can be well defined, the compiler will complain if anything is breaking. For this suggestion, I only don’t quite understand how the provider will catch the issue before the consumers come and find them. However, this idea did ring a bell in my mind to reconsider if I am too fixed to the microservice pattern and micro-frontend can have something completely different.

What’s your experience?