# mitra_app Maestro flows

End-to-end UI automation for the mitra Flutter app using [Maestro](https://maestro.mobile.dev). Single-emulator + curl-as-customer pattern — when a flow needs a customer to "do something", it's simulated via backend API calls fired from `runScript` steps.

## One-time install

See [client_app/.maestro/README.md](../../client_app/.maestro/README.md#one-time-install) — Maestro is a global CLI, install once and it serves both apps.

You also need:
- `adb` on your PATH (Android Studio platform-tools)
- `jq` (`apt install jq` / `brew install jq`)
- One Android emulator OR one connected device — **only one at a time** (per project decision)

## Folder layout

```
.maestro/
├── README.md                 # this file
├── config.yaml               # shared env: app IDs, backend URL, test credentials
├── flows/
│   ├── 01_smoke.yaml
│   ├── 02_online_offline_toggle.yaml
│   └── 03_accept_general_blast.yaml
└── scripts/
    └── customer_blast_now.sh
```

## Configure for your environment

Edit `.maestro/config.yaml` and fill in:
- `BACKEND_URL` — must match the `--dart-define=API_BASE_URL=...` value the installed APK was built with
- `TEST_CUSTOMER_ID` and `TEST_CUSTOMER_JWT` — used by the curl harness to fire blasts toward this mitra

## Run a flow

```bash
maestro test mitra_app/.maestro/flows/01_smoke.yaml

# all flows
maestro test mitra_app/.maestro/flows/
```

If multiple devices are attached:
```bash
adb devices
maestro --device emulator-5554 test mitra_app/.maestro/flows/01_smoke.yaml
```

## Per-machine overrides

Override config.yaml values at runtime:

```bash
maestro test \
  --env BACKEND_URL=http://192.168.99.10:3000 \
  --env TEST_CUSTOMER_JWT=eyJhbGc... \
  mitra_app/.maestro/flows/03_accept_general_blast.yaml
```

## Single-emulator + curl pattern

This mirrors the client_app pattern. When a mitra-side flow needs the customer to act, the flow uses `runScript:` to fire the customer's API calls directly:

1. Mitra app is on screen via Maestro on the only connected device
2. `runScript: ../scripts/customer_blast_now.sh` creates + confirms a payment_session and fires a chat request as a "fake" customer
3. The mitra app receives the blast via WS as it would from a real customer; Maestro asserts the overlay appears

For the customer-side equivalent (drive customer with Maestro, simulate mitra via curl), see [`client_app/.maestro/`](../../client_app/.maestro/).

## When to run mitra flows vs. client_app flows

- **Default**: drive the customer side via `client_app/.maestro/`. Most Phase 3.7 assertions live there (CTA gating, payment screen, searching screen, failed-pairing terminal, "Curhat lagi" overlays).
- **Run mitra flows when** you specifically need to assert mitra UI:
  - Returning-chat 20s countdown actually visible + ticking
  - Extension card copy reads "otomatis disetujui"
  - Online/offline toggle behavior (Section J — mitra goes offline mid-session)
  - Incoming-request overlay accept/decline buttons

## Adding a new flow

See [client_app/.maestro/README.md](../../client_app/.maestro/README.md#adding-a-new-flow) — same pattern.

## Troubleshooting

See [client_app/.maestro/README.md](../../client_app/.maestro/README.md#troubleshooting) — same checklist applies.