Интеграционные тесты для Flutter (integration tests) — это ваш главный инструмент против регрессий. Когда приложение приносит деньги, каждый краш на продакшене — потеря. Мы регулярно видим проекты, где widget-тесты проходят, а пользователь не может оформить заказ из-за бага в навигации. Widget-тесты работают в изолированном окружении: они не эмулируют реальный рендеринг, анимации и системные вызовы. Integration-тесты на реальных устройствах вылавливают такие сценарии до релиза. Наша команда с 5-летним опытом в Flutter пишет интеграционные тесты, которые сокращают количество критических багов на 70%. Один наш клиент после внедрения integration-тестов обнаружил 12 скрытых багов в корзине, которые не выявляли widget-тесты за полгода. Получите такую же стабильность — закажите аудит вашего проекта, мы оценим его за 1 день.
По данным официальной документации Flutter, integration-тесты позволяют проверить полные пользовательские сценарии с реальной синхронизацией анимаций и диалогов. Это единственный способ гарантировать, что оформление заказа работает на всех устройствах.
Как написать первый integration-тест?
Современный способ — пакет integration_test из Flutter SDK. Он заменил устаревший flutter_driver начиная с версии 2.5.
pubspec.yaml:
dev_dependencies: integration_test: sdk: flutter flutter_test: sdk: flutter Структура директорий:
integration_test/ app_test.dart test_driver/ integration_test.dart # только для запуска через flutter drive Запуск на подключённом устройстве:
flutter test integration_test/app_test.dart Запуск в Firebase Test Lab или BrowserStack — через flutter build apk --target integration_test/app_test.dart + загрузка APK.
Типичный тест покрывает полный пользовательский флоу: открыл приложение → авторизовался → перешёл в каталог → добавил товар → оформил заказ → увидел подтверждение.
void main() { IntegrationTestWidgetsFlutterBinding.ensureInitialized(); testWidgets('Full checkout flow', (tester) async { app.main(); await tester.pumpAndSettle(); await tester.enterText(find.byKey(Key('email')), '[email protected]'); await tester.enterText(find.byKey(Key('password')), 'password123'); await tester.tap(find.byKey(Key('login_btn'))); await tester.pumpAndSettle(timeout: Duration(seconds: 10)); expect(find.byKey(Key('home_screen')), findsOneWidget); await tester.tap(find.byKey(Key('product_card_1'))); await tester.pumpAndSettle(); await tester.tap(find.byKey(Key('add_to_cart_btn'))); await tester.pumpAndSettle(); expect(find.text('1'), findsOneWidget); }); } pumpAndSettle(timeout: Duration(seconds: 10)) — таймаут обязателен. Без него на слабом эмуляторе тест упадёт раньше, чем завершится анимация.
Какие сценарии стоит покрывать интеграционными тестами?
Покрывайте критический путь пользователя: авторизация, поиск товаров, добавление в корзину, оформление заказа, платёж. Сценарии с deep linking, push-уведомлениями и фоновыми задачами тоже требуют проверки. Из нашего опыта, 80% критических багов приходится на 20% сценариев. Начните с них — это даст максимальную отдачу.
Почему integration-тесты бывают нестабильными?
Flaky-тесты — распространённая проблема. Основные причины и решения:
Три главные причины flaky и их решения
| Причина | Решение |
|---|---|
| Бесконечные анимации (индикаторы, Lottie) | Использовать tester.pump(Duration(milliseconds: 500)) и waitFor |
| Клавиатура перекрывает кнопку | await tester.testTextInput.receiveAction(TextInputAction.done) или FocusManager.instance.primaryFocus?.unfocus() |
| Таймаут теста | Увеличить: @Timeout(Duration(minutes: 5)) |
По нашим данным, 90% flaky-тестов вызваны тремя указанными причинами. Используйте pump с явным ожиданием виджета — это снижает вероятность ложных падений на 60%. Widget-тесты выполняются быстрее, но integration-тесты находят в 4 раза больше багов, связанных с навигацией и анимациями. Это подтверждает наш опыт: после перехода на integration-тесты время на отладку сократилось на 40%.
Как настроить параллельный запуск в CI?
Один тест-файл — одна сессия устройства. Для параллельного прогона используем матрицу в GitHub Actions:
strategy: matrix: test-file: [auth_test.dart, checkout_test.dart, profile_test.dart] steps: - run: flutter test integration_test/${{ matrix.test-file }} Каждый job получает свой эмулятор через reactivecircus/android-emulator-runner@v2.
Работа с сетью: реальный бэкенд или моки?
Реальный бэкенд требует тестовой среды (staging) с фиксированными данными. Мок-сервер — используем mockito/mocktail на уровне репозитория или локальный HTTP-сервер через пакет shelf. Второй вариант ближе к реальности: приложение делает настоящий HTTP-запрос, но на localhost:8080. Переключение через --dart-define=API_BASE_URL=http://localhost:8080.
Реальный кейс: как integration-тест спас релиз
На одном из проектов перед релизом мы запустили integration-тест на оформление заказа. Тест упал на этапе выбора способа оплаты — оказалось, что после обновления библиотеки платежей кнопка оплаты стала недоступна при определённой ширине экрана. Widget-тесты этого не заметили, так как не рендерили реальный UI. Баг исправили за час, релиз прошёл без проблем.
Что входит в работу?
- Аудит текущей архитектуры приложения
- Разработка стратегии тестирования
- Написание integration-тестов для ключевых пользовательских сценариев
- Интеграция тестов в CI/CD (GitHub Actions, GitLab CI)
- Настройка параллельного запуска на эмуляторах
- Документация по запуску и поддержке
- Обучение команды заказчика
Сроки и стоимость
| Объём работ | Сроки |
|---|---|
| 3–5 ключевых флоу (авторизация, каталог, заказ) | 3 дня |
| Сложные сценарии (платежи, глубокая навигация) | до 5 дней |
| Полное покрытие приложения | от 2 недель |
Стоимость рассчитывается индивидуально после аудита. Получите консультацию — оценим ваш проект за 1 день.
Гарантируем: 2 месяца бесплатной поддержки после сдачи. Более 20 успешных проектов с Flutter.
Свяжитесь с нами для бесплатной консультации — мы проанализируем ваше приложение и предложим стратегию тестирования.