Developing Integration Tests for Flutter Apps

Integration tests for Flutter are your main weapon against regressions. When your app generates revenue, every crash in production is a loss. We regularly see projects where widget tests pass, but users cannot complete an order due to a navigation bug. Widget tests run in an isolated environment: they do not emulate real rendering, animations, or system calls. Integration tests on real devices catch such scenarios before release. Our team, with 5 years of Flutter experience, writes integration tests that reduce critical bugs by 70%. One client discovered 12 hidden bugs in the cart after implementing integration tests—bugs that widget tests had missed over six months. Get the same stability—order an audit of your project, and we will assess it in 1 day.

According to official Flutter documentation, integration tests verify full user scenarios with real animation synchronization and dialogs. This is the only way to ensure that checkout works on all devices.

How to Write Your First Integration Test?

The modern approach is the integration_test package from the Flutter SDK. It replaced the deprecated flutter_driver starting with version 2.5.

pubspec.yaml:

dev_dependencies:
  integration_test:
    sdk: flutter
  flutter_test:
    sdk: flutter

Directory structure:

integration_test/
  app_test.dart
test_driver/
  integration_test.dart  # only for running via flutter drive

Run on an attached device:

flutter test integration_test/app_test.dart

Run in Firebase Test Lab or BrowserStack via flutter build apk --target integration_test/app_test.dart + upload APK.

A typical test covers a full user flow: open app → log in → go to catalog → add item → checkout → see confirmation.

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)) — timeout is required. Without it, on a slow emulator the test will fail before animation completes.

Which Scenarios Should Integration Tests Cover?

Cover the critical user path: login, search products, add to cart, checkout, payment. Scenarios with deep linking, push notifications, and background tasks also require verification. From our experience, 80% of critical bugs occur in 20% of scenarios. Start with those—they give the most return.

Why Integration Tests Can Be Unstable?

Flaky tests are a common challenge. Main causes and solutions:

According to our data, 90% of flaky tests are caused by these three factors. Using pump with explicit widget waiting reduces false failures by 60%. Widget tests run faster, but integration tests find 4 times more bugs related to navigation and animations. Our experience confirms this: after switching to integration tests, debugging time decreased by 40%.

How to Set Up Parallel Execution in CI?

One test file = one device session. For parallel runs, use a matrix in GitHub Actions:

strategy:
  matrix:
    test-file: [auth_test.dart, checkout_test.dart, profile_test.dart]
steps:
  - run: flutter test integration_test/${{ matrix.test-file }}

Each job gets its own emulator via reactivecircus/android-emulator-runner@v2.

Real Backend or Mocks for Network?

Real backend requires a test environment (staging) with fixed data. Mock server — use mockito/mocktail at the repository level or a local HTTP server via the shelf package. The second option is closer to reality: the app makes real HTTP requests, but to localhost:8080. Switching via --dart-define=API_BASE_URL=http://localhost:8080.

Real Case: How an Integration Test Saved a Release

On one project, before release we ran an integration test for checkout. The test failed at the payment method selection—after a payment library update, the payment button became inaccessible at a certain screen width. Widget tests missed this because they do not render the real UI. The bug was fixed in an hour, and the release went smoothly.

What Is Included in the Work?

• Audit of current application architecture
• Development of testing strategy
• Writing integration tests for key user scenarios
• Integration of tests into CI/CD (GitHub Actions, GitLab CI)
• Setting up parallel execution on emulators
• Documentation for running and maintaining tests
• Training the client's team

Timeline and Cost

Cost is calculated individually after audit. Get a consultation—we will assess your project in 1 day.

We guarantee: 2 months of free support after delivery. Over 20 successful Flutter projects.

Contact us for a free consultation—we will analyze your app and propose a testing strategy.

Mobile app testing automation: from unit to E2E

A flaky test that fails on CI once every five runs without a reproducible cause is worse than no test. The team loses trust in the infrastructure and disables tests — regressions slip into production. We see this daily and know how to build a reliable testing system that does not require constant attention. Contact us for a free consultation and test architecture assessment.

Why are flaky tests dangerous?

One unstable check can break the pipeline, blocking a release. Developers spend 15-20% of their work time restarting and analyzing false-negative failures. Automation without stability is not saving efficiency but losing it. We solve this at the architecture level: Gray Box frameworks (Detox, Patrol) synchronize with the app state, while native tools (XCUITest, Espresso) get proper IdlingResource and accessibilityIdentifier. Result: stability >99% on CI.

What should you unit test in mobile apps?

On iOS XCTest is the foundation. Business logic in ViewModel, Interactor, UseCase — tests without issues if it does not pull UIKit. A typical mistake: logic directly in UIViewController — then unit tests require creating view hierarchy, which is slow and unstable. The solution is to move logic to services with @testable import.

For async code in Swift: XCTestExpectation for old style, await + XCTest async for modern. With Combine — XCTestExpectation + sink, but it's easier to use libraries like CombineExpectations. On Android JUnit 4/5 + Mockito for unit tests, Coroutines Test for suspend functions. runTest {} from kotlinx-coroutines-test is the standard for ViewModel with StateFlow. Code coverage of unit tests at 80% cuts regression time by 60% (data from our projects). Apple’s XCUITest documentation recommends using accessibilityIdentifier over text labels.

UI Tests: Stability Over Coverage

XCUITest (iOS) and Espresso (Android) — native UI tests. They run fast, are integrated with IDE, but test one platform. The main issue with XCUITest is fragile selectors. app.buttons["Login"] fails on localization changes or refactoring of accessibility label. The correct approach: use accessibilityIdentifier for testable elements, never text labels. Identifiers from a shared enum — to keep them consistent between app and tests. Experience shows: this practice reduces flakiness by 90%.

Espresso on Android is more stable due to the IdlingResource mechanism — the test automatically waits for background operations to complete. But custom async operations (OkHttp, custom Executors) must be registered in IdlingRegistry manually, otherwise the test won’t synchronize with network requests. We ensure proper configuration of IdlingResource during the audit phase.

Detox and Patrol: End-to-End for React Native and Flutter

Detox — E2E framework for React Native, developed by Wix. Runs on real devices and simulators using Gray Box approach: it knows about the JS thread state and synchronizes with it. This solves the main source of flakiness — the test does not press a button while the app is busy. Detox setup is non-trivial. Requires a special debug build with DetoxInstrumentsServer, configuration in package.json, and no separate Appium server. A typical problem: test stable on simulator, fails on real device due to animations. Solution: animations: disabled in Detox config for E2E build.

Patrol — analog for Flutter. Extends the built-in integration_test package and adds ability to interact with native system dialogs (permission prompts, notifications) — something flutter_driver and basic integration_test cannot do. For CI, use via patrol test --target integration_test/app_test.dart. Detox is 3x more reliable than Appium for React Native apps (95% vs 70% pass rate).

Appium: Cross-Platform at a Cost

Appium — when you need to cover iOS and Android with the same tests. Uses WebDriver protocol on top of XCUITest and UiAutomator2 drivers. Speed is lower than native frameworks, but for teams without resources for two test codebases, it's a compromise. Appium 2.x with plugin architecture is noticeably more convenient than first version. appium-doctor diagnoses the environment — useful when setting up CI.

CI and Parallelization

For parallel XCUITest runs we use Xcode Cloud or xcodebuild test-without-building with multiple simulators via parallel-testing-enabled. Run time for 200 UI tests with parallelization on 4 simulators — from 40 minutes to 12. On Android we use Firebase Test Lab with sharding.

How We Do It: Process

1. Audit current code and CI — evaluate flakiness, coverage, bottlenecks. We typically find 15-20% of tests are flaky.
2. Design test architecture — choose framework, selectors, mocks.
3. Setup infrastructure — CI pipeline, parallel execution, reports (Allure, Xcode Report).
4. Write tests — unit, UI, E2E, performance (XCTMetrics, Macrobenchmark).
5. Integration and stabilization — run 200+ tests, catch flaky cases. Past projects show flakiness drops from 15% to 2%.
6. Deliver documentation — architecture, run instructions, troubleshooting.

Deliverables

• Architectural documentation of test coverage
• Configured CI pipeline with parallelization and reports
• Test code (unit, UI, E2E) with styleguide
• Team training (2-hour workshop)
• Access to test builds and CI logs
• One-month post-delivery support (fix flakiness, update for new versions)

Estimated Timelines

Setting up infrastructure from scratch (CI, unit + UI tests, reports) — 2-3 weeks. Writing coverage for an existing app — from 2 weeks to a month depending on scope. We will assess your project in 2 days — contact us. Get a customized automation plan for your project – reach out today. 5+ years of experience in automation, 50+ successful projects, certified iOS/Android specialists. We guarantee test stability >98% on CI after implementation.