🧩 Как тестировать микрофронтенд: гайд для команд, которые собирают пазл из нескольких приложений

Микрофронтенды дают гибкость, но превращают тестирование в задачу со звёздочкой. Когда UI собран из кубиков разных команд, классические подходы к тестам ломаются. Давайте разберёмся, как выстроить надёжную пирамиду тестирования, чтобы сборка не разваливалась на продакшене.

🔬 1. Начните с изолированных unit-тестов Каждый микрофронтенд — самостоятельное приложение. Значит, внутри него работают классические инструменты:

· Jest / Vitest для логики, утилит, хуков. · React Testing Library или аналог для тестирования компонентов в изоляции.

Важно: мокайте всё, что приходит из shell-приложения (общие сервисы, авторизацию, роутинг). Микрофронтенд должен тестироваться как отдельный модуль, не зависящий от окружения.

✅ 2. Тесты контрактов — ваш спасательный круг Микрофронтенды общаются через события, общие API или глобальный стор. Контракты должны быть протестированы:

· Если используется кастомная событийная шина — проверьте, что микрофронтенд слушает и отправляет события с корректной структурой. · При использовании Module Federation убедитесь, что shared-зависимости совместимы (версии React, библиотек). Здесь помогает инструмент @module-federation/utilities или ручная проверка совместимости в CI. · Для Single-spa проверяйте корректность export/import lifecycle-методов (mount/unmount) в тестах.

⚙️ 3. Интеграционные тесты в «песочнице» Прежде чем собирать всё вместе, протестируйте микрофронтенд в контексте shell, но без реальных соседей. Сделайте минимальный root-config, который монтирует только ваш MFE, и прогоните сценарии:

· Может ли он загрузиться и отрендерить начальное состояние? · Как он обрабатывает переходы внутри своей зоны роутинга? · Корректно ли анмаунтится и очищает глобальные слушатели?

Так вы отловите проблемы интеграции с оболочкой, не дожидаясь полного e2e.

🧪 4. End-to-end тесты всей композиции E2E-тесты необходимы, чтобы проверить, что кубики действительно состыковались. Советы:

· Используйте Cypress или Playwright — они хорошо работают с микрофронтендами. · Тестируйте сквозные пользовательские сценарии, которые затрагивают несколько MFE: авторизация → переход в личный кабинет → покупка. · Фикстуры данных должны быть стабильными, а стенд — максимально похож на продакшен (те же CDN, те же импорты). Иначе легко пропустить ошибки загрузки удалённых модулей.

🚀 5. Тестирование на стыке CI/CD и производительности

· В пайплайне запускайте тесты для каждого микрофронтенда изолированно и параллельно. · Проверяйте изоляцию стилей: можно делать скриншотные тесты с Percy или Chromatic, чтобы отловить «поплывшую» вёрстку из-за конфликта CSS. · Контролируйте размер бандлов и время загрузки remoteEntry — если микрофронтенд распух, это повлияет на скорость всей композиции.

💡 Ключевой принцип: тестируйте на том же уровне, на котором принимаете архитектурные решения. Если микрофронтенды независимы — тесты должны подтверждать эту независимость. Если они должны вместе решать одну бизнес-задачу — проверяйте именно совместное поведение.

Тестирование микрофронтендов не сложнее монолита — оно просто требует другого фокуса. Разложите проверки по уровням, автоматизируйте контракты и не забывайте про E2E на собранном приложении. Тогда архитектура «пазла» будет приносить удовольствие, а не головную боль.

Делитесь в комментариях, с какими граблями в тестировании MFE сталкивались вы 👇