ramadhan sjamsani
d09e50af55
- Backend: payment_sessions + pairing_failures tables; payment.service.js and pairing-failure.service.js (new); rewritten pairing.service.js (payment-gated blast + targeted "Curhat lagi" + cancel + fallback); rewritten extension.service.js (data-driven auto-approve with offline safeguard, charge-at-approval); pricing.service.js (extension tiers without free trial); mitra-status.service.js (countAvailableMitras cached path); 60s sweeper for stale payment sessions - Backend routes: client.payment.routes, client.mitra-availability.routes, internal/failed-pairings.routes; client.chat.routes rewritten for payment-gated start + /returning + /cancel + /fallback-to-blast; internal/config.routes adds 4 new keys with Valkey invalidate publish - client_app: mitra-availability poll, payment screen + notifier, pairing notifier rewrite (PairingTargetedWaiting + PairingFailed states), targeted-waiting overlay + bestie-unavailable dialog, "Curhat lagi" CTA, failed-pairing terminal, extension via payment-session - mitra_app: PairingRequestType enum, returning-chat 20s countdown auto-dismiss, extension card "otomatis disetujui" copy - control_center: 4 new config rows in Settings, Failed Pairings page (filter + paginate + action menu), sidebar + route registered - Test infrastructure: Vitest backend (7/7 pass), Playwright CC (4/4 pass), Maestro mobile scaffold (CLI install pending) - Bugs found via Playwright + fixed: LoginPage labels not associated with inputs (a11y); backend internal CORS missing PATCH/PUT/DELETE in allow-methods (silent settings breakage in browsers since Stage 4) - Docs: phase3.7.md PRD, phase3.7-plan.md, phase3.7-questions.md (Q&A), phase3.7-testing.md (E2E checklist), phase3.7-test-run-2026-05-03.md (today's run results) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
86 lines
3.2 KiB
Markdown
86 lines
3.2 KiB
Markdown
# 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.
|