Ramadhan Sjamsani
fcb8eaa505
- Customer: com.halobestie.client.client_app → com.mybestie - Mitra: com.halobestie.mitra.mitra_app → com.mybestie.mitra - iOS bundle IDs renamed to match (no .clientApp/.mitra camelCase legacy) Mechanical rename touches Android build.gradle/Manifest/MainActivity package, iOS pbxproj/Info.plist bundle IDs, Firebase configs (google-services.json + GoogleService-Info.plist + firebase_options.dart), new HaloBestie/Mitra launcher icons via flutter_launcher_icons (pubspec config + adaptive-icon resources + AppIcon imageset), and the appId references in every customer maestro flow + both .maestro/config.yaml files. brandLogoBg (#FF699F) added to halo_tokens for the launcher pink. Followup: re-register apps in Firebase consoles using the new package IDs; strategy memo at project-firebase-env-strategy. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
mitra_app Maestro flows
End-to-end UI automation for the mitra Flutter app using Maestro. 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 — Maestro is a global CLI, install once and it serves both apps.
You also need:
adbon 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 withTEST_CUSTOMER_IDandTEST_CUSTOMER_JWT— used by the curl harness to fire blasts toward this mitra
Run a flow
maestro test mitra_app/.maestro/flows/01_smoke.yaml
# all flows
maestro test mitra_app/.maestro/flows/
If multiple devices are attached:
adb devices
maestro --device emulator-5554 test mitra_app/.maestro/flows/01_smoke.yaml
Per-machine overrides
Override config.yaml values at runtime:
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:
- Mitra app is on screen via Maestro on the only connected device
runScript: ../scripts/customer_blast_now.shcreates + confirms a payment_session and fires a chat request as a "fake" customer- 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/.
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 — same pattern.
Troubleshooting
See client_app/.maestro/README.md — same checklist applies.