Testing

Critical flows are proven before every release, including the native dialogs Flutter tests often skip.

Clay illustration of mobile testing
Testing featured graphic

How it works

A left-to-right map of the work. Ports stay on fixed sides so the edges do not cross more than they have to. Pan or pinch if you want a closer look.

The usual problem

  • Widget tests pass while a permission dialog still blocks a real user.
  • The journeys that make money are the ones nobody automates.
  • A release is “tested” when someone tapped through it once on their phone.

How I approach it

  • Patrol covers the journeys that matter, including native dialogs and permissions.
  • Widget and integration tests sit under that, not instead of it.
  • The suite runs in CI. A red build does not ship.

Process

  1. 01

    Pick the journeys

    A written list of the flows that cannot break.

  2. 02

    Automate

    Patrol on those journeys; widget and integration tests around them.

  3. 03

    Gate

    The suite runs on every pull request.

  4. 04

    Handover

    A test suite in CI and a list of what is covered.

Stack and tools

PatrolWidget testsIntegration testsCI

Proof from real work

Kadipay

Mobile lead

Patrol on the key repair-financing flows.

Open the case study

MDBriefcase

Flutter engineer

Unit, widget, and Patrol integration tests on learning flows.

Open the case study

What you get

  • A test suite wired into CI
  • A written list of covered flows

How risk stays down

  • Native dialogs and permissions are part of the suite, not a manual leftover.
  • The same tests run on every PR, so coverage does not depend on who is in the office.

Questions agencies ask