Разработка Widget-тестов для Flutter-приложения

Разработка Widget-тестов для Flutter-приложения

Мы часто сталкиваемся с ситуацией: вы написали виджет, запускаете тест — и получаете No MaterialApp found или RenderFlex overflow. Знакомо? Widget-тесты во Flutter занимают нишу между юнит-тестами (слишком мелко) и интеграционными (слишком медленно). В отличие от интеграционных тестов, которые гоняют приложение на устройстве, widget-тесты рендерят виджеты в синтетическом окружении WidgetTester за миллисекунды — это в 10–20 раз быстрее. Они позволяют быстро проверить рендеринг, взаимодействия пользователя и состояния UI без симулятора.

Типичные проблемы, с которых начинают

Первая и самая частая ошибка — попытка написать widget-тест для виджета, который завязан на реальный BuildContext. Например, виджет использует Theme.of(context) и падает с No MaterialApp found или No Directionality widget. Решение — всегда оборачивать тестируемый виджет в MaterialApp или минимальный Directionality:

await tester.pumpWidget( MaterialApp(home: MyWidget()), ); 

Вторая распространённая проблема — RenderFlex overflowed в тестах, которого не было в дебаггере. Это происходит, потому что размер WidgetTester по умолчанию (800×600) не совпадает с реальным устройством. Исправляем через tester.binding.window.physicalSizeTestValue или в актуальном Flutter 3.x API: tester.view.physicalSize = const Size(390, 844).

Третья проблема — асинхронность. Widget-тесты синхронны по умолчанию, но часто виджеты полагаются на Future, Stream или анимации. Без правильного pump() тест либо зависнет, либо пройдёт без ожидания результата. Разберём это детально.

Как избежать RenderFlex overflow в тестах?

Параметр SurfaceSize по умолчанию — 800×600. Для мобильных экранов это часто приводит к overflow. Наш опыт показывает, что лучше задавать размер под конкретное устройство. Используем setSurfaceSize (добавлено в Flutter 3) или старый physicalSizeTestValue. Пример для iPhone 13:

tester.view.physicalSize = const Size(390, 844); 

Обязательно сбрасываем в tearDown:

tearDown(() { tester.view.resetPhysicalSize(); }); 

Архитектура виджет-тестов

Структура тест-файла соответствует структуре виджета: test/widgets/ зеркалит lib/widgets/. Каждый тест-файл — один виджет или один экран. Это упрощает навигацию и поддержку.

group('LoginScreen', () { testWidgets('shows error when email is invalid', (tester) async { await tester.pumpWidget(MaterialApp(home: LoginScreen())); await tester.enterText(find.byKey(Key('email_field')), 'not-an-email'); await tester.tap(find.byKey(Key('submit_button'))); await tester.pump(); // синхронный кадр expect(find.text('Введите корректный email'), findsOneWidget); }); }); 

pump() vs pumpAndSettle() — критичное различие. pump() рисует один кадр. pumpAndSettle() крутит кадры до тех пор, пока не останется pending-анимаций. На виджетах с бесконечными анимациями (AnimatedBuilder с repeat: true) pumpAndSettle() зависнет навсегда — используем pump(Duration(seconds: 2)).

Как мокировать провайдеры в тестах?

Widget-тест без мокирования зависимостей — это не виджет-тест, а интеграционный. Мы гарантируем, что каждый тест изолирован. Для разных state-менеджеров подходы различаются:

Важно: в GetIt не забывайте сбрасывать регистрацию в tearDown — иначе мок перетечёт в соседний тест. Для BLoC удобно использовать mocktail, для Riverpod — mockito или riverpod_generator.

Golden Tests: зачем и как?

Golden Tests — это визуальные регрессионные тесты. Виджет рендерится, скриншот сравнивается с эталонным .png в test/goldens/. При первом запуске эталон генерируется (flutter test --update-goldens), при последующих — любое пиксельное расхождение ломает тест. Это даёт гарантию, что UI не изменился неожиданно. Golden Tests лучше стандартных визуальных проверок, так как автоматически выявляют пиксельные расхождения, недоступные глазу.

testWidgets('PrimaryButton golden', (tester) async { await tester.pumpWidget( MaterialApp( home: Center(child: PrimaryButton(label: 'Сохранить')), ), ); await expectLater( find.byType(PrimaryButton), matchesGoldenFile('goldens/primary_button.png'), ); }); 

Однако Golden Tests платформо-зависимы. Шрифты, сглаживание, рендеринг теней — всё различается на macOS, Linux и Windows CI. Решение — запускать golden-тесты только на одной платформе, используя canvaskit рендерер или Docker-образ.

Пакет golden_toolkit добавляет loadAppFonts(), что устраняет прямоугольники вместо текста в эталонах. Наш опыт показывает: golden-тесты на компонентной библиотеке (10–20 виджетов) настраиваются за 2–3 дня.

Async и Future в тестах

Если виджет запускает Future при инициализации (например, FutureBuilder + HTTP-запрос), в тесте нужно контролировать завершение этого future. Без мока сетевой вызов либо упадёт, либо зависнет. Используем mocktail:

when(() => mockApiService.getUser()).thenAnswer((_) async => mockUser); await tester.pumpWidget(/* ... */); await tester.pump(); // запускает FutureBuilder await tester.pump(Duration.zero); // ждём завершения Future 

Fake вместо Mock — когда поведение сложное. Реализуем FakeAuthService extends AuthService, переопределяем нужные методы — чище, чем stub каждого вызова.

Что входит в работу

• Написание widget-тестов для всех ключевых экранов и компонентов
• Настройка Golden Tests с корректной платформой для CI (гарантируется прохождение на вашем CI)
• Мокирование провайдеров (Riverpod, BLoC, Provider, GetIt)
• Покрытие edge-кейсов: пустые состояния, ошибки, loading
• Настройка запуска в CI с отчётом о покрытии (coverage >= 80% на виджетах)

Сроки и стоимость

3–5 дней для проекта со стандартным набором экранов (10–20 виджетов). Golden Tests на весь UI компонентной библиотеки — отдельная оценка. Стоимость рассчитывается индивидуально — пишите, оценим ваш проект.

Почему стоит доверить тесты профессионалам?

У нас за плечами десятки Flutter-проектов с коммерческим запуском в App Store и Google Play. Мы знаем, какие грабли встречаются на пути: от overflow до golden-расхождений на CI. Мы гарантируем, что ваши виджет-тесты будут стабильными, быстрыми и поддерживаемыми. Свяжитесь с нами, чтобы обсудить детали и получить консультацию.