mobile-dev-inc / maestro

Painless Mobile UI Automation
https://maestro.mobile.dev/
Apache License 2.0
5.64k stars 255 forks source link

[Feature Request] Shell script support for WireMock #1250

Open timrijckaert opened 1 year ago

timrijckaert commented 1 year ago

Is your feature request related to a problem? Please describe. I wish to use WireMock in my Maestro test flows.
My test flows would first configure the responses before starting the app. This can be done by using the Admin API that WireMock offers and Maestro's HTTP Request support in Javascript

Therefore I wish to use the onFlowStart and onFlowComplete commands to run arbitrary scripts

flow.yaml

appId: ${APPID}
onFlowStart:
- runScript: 'start-wiremock.sh'
- runScript: "perform-http-requests-to-wiremock-to-change-stubbing.js"
onFlowComplete:
- runScript: 'stop-wiremock.sh'
---
- ...

I would stop my WireMock which each run so stubs are reset to defaults. Currently I have no way of doing this.

Describe the solution you'd like The runScript block should allow running arbitrary shell scripts.

Additional context Similar to #247

mdethlefs commented 1 year ago

This would be amazing!

otoniel-isidoro commented 1 year ago

it can help for now https://testableapple.com/gaining-access-to-command-line-from-maestro/

axelniklasson commented 11 months ago

@timrijckaert could you share more about what specific funcitonality in bash script you rely on and what is missing in the JavaScript support to allow WireMock API integration?

timrijckaert commented 10 months ago

I worked around the problem by using HTTP request in JavaScript to stub WireMock requests. And wrapping the maestro shell script to start WireMock myself 🥲

However the issue is broader than just using WireMock Ideally any arbitrary shell script can be used to extend the functionality of Maestro. Especially in combination with the onFlowStart and onFlowComplete For example #1253, I could simply fire these adb commands before every test run without having this built in Maestro.

In previous issues (#247) the concern was this would conflict with Maestro running in the cloud. I'm totally fine not having this as we run Maestro purely locally as I think the majority here.