Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Command line arguments to app when testing #181

Closed
adamski opened this issue Jul 2, 2017 · 4 comments
Closed

Command line arguments to app when testing #181

adamski opened this issue Jul 2, 2017 · 4 comments

Comments

@adamski
Copy link

adamski commented Jul 2, 2017

I'd like to invoke a switch in the native part of my app when testing, in this case to mock audio input. I've been looking for a way to pass a command line argument to the app but not found anything - is there a way to do this with Detox? If not I'm happy to create a PR.

@adamski
Copy link
Author

adamski commented Jul 2, 2017

Looking at the code, my proposal would be to add command line arguments here

https://github.com/adamski/detox/blob/master/detox/src/devices/DeviceLoader.js#L22

e.g.

// Set this somewhere
var args = ["-test", "true"];

//... 

await fbsimctl.launch(simulatorUdid, bundleId, args)

@LeoNatan
Copy link
Contributor

LeoNatan commented Jul 5, 2017

We've been discussing this internally for a while. In general, I don't like people having if(testing) { ... } else { ... } code in their apps, be it native or JS. Just doesn't look like a good idea in long term code management, in addition to localized problems of enabling test code by mistake.

On the JS front, we are working on a solution that allows you to mock stuff at the "compiler" level - during packaging. I'd love to have a similar solution for native, where at detox build time, we would be able to perform injections. This has many challenges, such as Swift support, how to inject, etc. I have not given thought on how to approach a solution yet.

@adamski
Copy link
Author

adamski commented Jul 6, 2017

Totally fair points here, I also don't like the if(testing) then (mock) else (real code) kind of approach either. Turns out in the app I'm working on it doesnt actually matter so much (it could record silence and it would be ok) but would be great to somehow mock audio input, perhaps as you suggest 'injecting' alternative classes that e.g. play back an audio file instead of recording from the mic input but its something that requires some thought and research.

@rotemmiz
Copy link
Member

@wix wix locked and limited conversation to collaborators Jul 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants