Repository metrics
- Stars
- (10,558 個のスター)
- PR merge metrics
- (PR metrics pending)
説明
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 called auto - 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.
"devices": {
"android": {
"type": "android.emulator",
- "device": {
- "avdName": "auto"
- }
}
}
==> Implies 'auto'
This will have to come with a cost elsewhere, of course:
- Have
detox testwarn 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 initsuch that it would allow for modifying the emulator at a later step. For thedetox initcase - have it propose to do so interactively (i.e. have it runadb devicesbehind the scenes and prompt the user for a device selection, etc.).
* BTW, this is how Android (native) instrumentation testing works.