集成测试策略

Welcome to Integration Testing for Micro Frontends! This lesson focuses on how to test the connections and interactions between different parts of your federated application.

While unit tests check individual components, integration tests ensure that multiple Micro Frontends (MFEs) or shared modules work correctly together as a cohesive system.

In a Micro Frontend architecture, different teams often develop parts of the application independently. This brings great flexibility but also unique testing challenges.

• Verify Interactions: Ensure MFEs communicate correctly.
• Catch Integration Bugs: Find issues where components don't fit together.
• Boost Confidence: Deploy with assurance that your federated app works.

It's crucial because a bug in how two MFEs interact can break the entire user experience.

Testing interactions across independent applications isn't always straightforward. Here are some common hurdles:

• Environment Setup: Replicating a full federated environment for tests can be complex.
• Dependency Management: Handling multiple remote modules and their versions.
• Test Isolation: Ensuring tests don't interfere with each other when crossing MFE boundaries.
• Performance: Integration tests are typically slower than unit tests.

We'll explore strategies to overcome these challenges.

When designing integration tests for Micro Frontends, focus on these principles:

• Test Contracts: Verify that exposed interfaces and consumed APIs (data shapes, function signatures) are compatible.
• End-to-End Flows: Test critical user journeys that span multiple MFEs.
• Data Propagation: Ensure data updates correctly across shared state or communication channels.
• UI Composition: Check that different MFE UIs render and interact as expected when composed together.

Avoid re-testing internal logic already covered by unit tests.

Various tools can help with MFE integration testing:

• Jest / React Testing Library: Great for component-level integration, testing how a host consumes a remote component in isolation.
• Cypress / Playwright: Excellent for end-to-end (E2E) testing, simulating real user interactions across multiple deployed MFEs in a browser.
• Mock Service Worker (MSW): For mocking API calls and network requests, useful when testing MFEs that rely on backend services.

The choice depends on the scope and depth of your integration tests.

A common MFE integration point is a host application consuming a component or utility exposed by a remote application via Module Federation.

We need to verify the host correctly receives and uses what the remote provides. Here's a simplified JavaScript example to illustrate the concept of a shared utility being consumed:

Many Micro Frontends communicate using an event bus or custom events. Integration tests should ensure events are dispatched and handled correctly across MFE boundaries.

You can simulate these events in your tests and assert that the receiving MFE reacts as expected. Here's a conceptual test snippet:

// In a test file (e.g., using Jest)

describe('MFE A dispatches, MFE B reacts', () => {
  test('MFE B updates state after MFE A event', () => {
    // 1. Render MFE B (the listener)
    const { getByText } = render(<MFEBComponent />);

    // 2. Simulate MFE A dispatching an event
    //    (e.g., via a global event bus or DOM event)
    window.dispatchEvent(new CustomEvent('userLoggedIn', {
      detail: { username: 'testuser' }
    }));

    // 3. Assert MFE B's UI or state updated
    expect(getByText('Welcome, testuser!')).toBeInTheDocument();
  });
});

This checks the communication contract.

If your MFEs share a global state store (e.g., Redux, Zustand), integration tests must verify that changes in one MFE correctly update the shared state, and that other MFEs consuming that state react appropriately.

This often involves rendering multiple MFEs in a test environment and simulating user interactions:

// Conceptual test for shared state

describe('Shared user profile state', () => {
  test('MFE A update reflects in MFE B', async () => {
    // 1. Render Host app with MFE A and MFE B
    const { getByLabelText, getByText } = render(<HostApp />);

    // 2. Simulate user action in MFE A (e.g., update profile name)
    fireEvent.change(getByLabelText('Name Input'), { target: { value: 'Jane Doe' } });
    fireEvent.click(getByText('Save Profile'));

    // 3. Assert MFE B (which displays profile) shows the new name
    await waitFor(() => {
      expect(getByText('Profile Name: Jane Doe')).toBeInTheDocument();
    });
  });
});

This ensures state consistency across your federated application.

Sometimes, you don't need to load *all* remote MFEs for every integration test. You might want to mock specific remote modules or their dependencies.

• Why mock? Faster tests, isolating failures, testing specific scenarios (e.g., remote MFE failure).
• How to mock: Use your testing framework's mocking capabilities (e.g., Jest's jest.mock()) to replace a remote component or function with a controlled test double.

// Example of mocking a remote component

jest.mock('remoteApp/Button', () => ({ 
  __esModule: true, 
  default: ({ onClick, children }) => (
    <button onClick={onClick} data-testid="mock-button">
      {children} (Mocked)
    </button>
  ),
}));

This allows you to test the host's logic without needing the actual remote.

What is the primary goal of integration testing in a Micro Frontend architecture?

Great job! You've learned about crucial strategies for integration testing in Micro Frontends:

• Integration tests verify interactions between MFEs and shared modules.
• They address unique challenges like environment setup and test isolation.
• Focus on testing contracts, data flow, and cross-MFE communication.
• Tools like Jest, React Testing Library, Cypress, and Playwright are essential.
• Techniques include testing component consumption, event handling, shared state, and strategic mocking.

By applying these strategies, you can build more robust and reliable federated applications. Keep practicing!