You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the Google emulators case, which is the common case when using Detox (on Android), it is mandatory for the onboarding developer to run adb devices / check Android Studio / dig into the SaaS machine's setup in order to select the emulator Detox should run on. While more fail-proof, as a process, it is a bit clunky and probably helps over-complicate the already complex setup flow.
My proposal is that initially, Detox would be integrated (e.g. using detox init) such that the device to use would be in a special mode called auto - which would tell Detox to auot-select an emulator*, based on some logic:
Alternatively, the default behavior could be selected in response to not having avd-name specifics in the configuration, so as to ease even further both the developer and our config parsing logic.
This will have to come with a cost elsewhere, of course:
Have detox test warn that an emulator has been auto-selected, explaining why (link to troubleshooting guide / setup section) and which specific emulator it chose.
Extend the onboarding guide and detox init such that it would allow for modifying the emulator at a later step. For the detox init case - have it propose to do so interactively (i.e. have it run adb devices behind the scenes and prompt the user for a device selection, etc.).
* BTW, this is how Android (native) instrumentation testing works.
The text was updated successfully, but these errors were encountered:
Any update on this point? I'm developing a small CLI to give the user the power to select available virtual devices. It's not a very pretty solution but it will have to be that way for now.
Describe your idea
For the Google emulators case, which is the common case when using Detox (on Android), it is mandatory for the onboarding developer to run
adb devices
/ check Android Studio / dig into the SaaS machine's setup in order to select the emulator Detox should run on. While more fail-proof, as a process, it is a bit clunky and probably helps over-complicate the already complex setup flow.My proposal is that initially, Detox would be integrated (e.g. using
detox init
) such that the device to use would be in a special mode calledauto
- which would tell Detox to auot-select an emulator*, based on some logic:"devices": { "android": { "type": "android.emulator", "device": { + "avdName": "auto", } } }
Or, in a way, slightly more idiomatic:
"devices": { "android": { "type": "android.emulator", + "name": "auto", } }
Alternatively, the default behavior could be selected in response to not having avd-name specifics in the configuration, so as to ease even further both the developer and our config parsing logic.
==> Implies 'auto'
This will have to come with a cost elsewhere, of course:
detox test
warn that an emulator has been auto-selected, explaining why (link to troubleshooting guide / setup section) and which specific emulator it chose.detox init
such that it would allow for modifying the emulator at a later step. For thedetox init
case - have it propose to do so interactively (i.e. have it runadb devices
behind the scenes and prompt the user for a device selection, etc.).* BTW, this is how Android (native) instrumentation testing works.
The text was updated successfully, but these errors were encountered: