Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Any plans to address integration testing between these components? #7

Open
snowystinger opened this issue Nov 17, 2017 · 2 comments
Open

Comments

@snowystinger
Copy link

As a micro frontend architecture with teams updating independently, it's a good idea to have some level of integration testing. How can this be handled? Does the overall container application specify a specific version of each component it's loading?

naltatis added a commit that referenced this issue Nov 17, 2017
@naltatis
Copy link
Member

naltatis commented Nov 17, 2017

This is indeed a tricky topic.

Features inside one vertical are tested by the team itself. This is where we write most of our tests.

To make sure all pieces work together we also had projects where we've implenented an additional higher level integration test that tests a complete customer journey (eg. from homepage through checkout). For this to work the team responsible for this test must have a reliable way of identifying the relevant parts on the page (buy button, success messages, ...). The requires some coordination.

Another alternative is, that each team directly tests its direct integration points with the other teams.

I've added integration testing to my writing todo list.

@ChristianUlbrich
Copy link

Why would integrations tests have to be any different for micro-frontends? Micro-Frontends are an architectural style to build big apps. If you want to test functionality across function verticals, you employ exactly the same methods that you'd emloyed to test yarr big olde' monolithic app. But using a composition-based approach, you can:

  • version your components and hopefully rely on them sticking to SemVer and thus prevent breaking things by using meaningful versions (as you suggest); one feasible, but very specific approach for this is Canopy's Sofe
  • test your components in an isolated way

If you understand components not as a mere "buy button" but an app feature (in contrast to a product feature) that are developed in real verticals (meaning they are aligned with the backend) - you can considerably narrow down the test effort. As @naltatis says, you'd want to do most of your tests at the component level and only do few high-level integration tests. Of course with a micro-frontend architecture you could test the integration of different components isolated from the real app in a small testbed application to make sure, that this combination will work in your real app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants