JavaScript Composability, micro-frontends and e2e testing
What is e2e testing?
Unlike unit testing, or integration testing, that test a functionality in isolation, or the integration of two or more units, end-to-end testing tests an application from one end to another. This means that it goes over the application like a user would, if they would use all its functionality, making sure there are no usability or functionality gaps. That of course requires that all the components involved, work properly.
How does it work?
For example if we’re testing an e-commerce application built with composable frontends, and the catalogue is one horizontal frontend, and the cart is another one, and there is a payment service to make sure we can complete the checkout, writing e2e tests will help us verify that all those parts are functional and we can go from rendering the items in the catalogue, to adding them to the cart, removing them from the cart, paying, etc.
Basically, what we are testing are those user events that trigger system operations like rendering and compute, to complete a workflow from start to finish.
A code example
You can see an example of end-to-end testing in our micro frontends sample and in our AI sample where we have end-to-end testing with Playwright. I suggest you visit the docs to learn more about this amazing tool. Personally, it’s one of my favorite tools and APIs.
Adding end-to-end testing to your development pipelines
Because of how micro frontend teams work independently and isolation, you want to make sure the end-to-end health of your composable applications is verified every time a team pushes changes.
Governance should prescribe a test is build for every new functionality and the CI/CD pipeline should require the tests are run every time new code is checkedin.
For our AI Sample, where a chat component built with Web Components and Lit is bootstrapped to a React shell, we run Playwright tests on integration to our main and develop branches.
name: Playwright Tests
on:
push:
branches: [main, develop]
pull_request:
branches: [main, develop]
jobs:
test:
timeout-minutes: 60
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 18
- name: Install dependencies
run: npm ci
- name: Install Playwright Browsers
run: npm run install:playwright
- name: Run Playwright tests
run: npm run test:playwright
- uses: actions/upload-artifact@v4
if: failure()
with:
name: playwright-report
path: playwright-report/
retention-days: 30You can see the workflow file here. This guarantees that no matter what team is pushing changes, the workflow is not broken.