For now, we can launch the app with launchArgs
await device.launchApp({launchArgs: {arg1: 1, arg2: "2"}});
but in many cases, it's easier to pass in environment variables, like this
await device.launchApp({environ: {API_URL: 'http://localhost:3000'}});
as launchArgs require parsing, while environment variable can be read directly with simple key. So I think it would be nice to add support for launching the app with environment variables.
What is your use case here?
Remember, with Detox you should be testing your app as close to what the user experience is. The user cannot set environment variables (or launch arguments).
@LeoNatan the use case we had at Envoy is, we sometimes needs to set a different configuration value for testing purpose, such as API_URL mentioned above, which is a perfect example. Surely user cannot set the environment variable, nor change the launch arguments, but the problem is just because so, we cannot change things like API_URL to a local API server that servers mock API endpoints via user interface, we need to change it via environment or launch argument.
Besides API, there is also stuff we need to mock via feeding a different environment variable to the app. For example, our Envoy sign-in app supports badge printing, to test the badge printer, there is no way we make the iPad really print the badge out and somehow ensure the badge printing is correct.
In that case, we will need to feed in an environment variable telling the app to use a mock printer module, and talk to our local HTTP server instead, and the HTTP server is running with our tester, so that we can check the parameters sending to the mock printer server, and we can see if it's working as expected. Like this
BADGE_PRINTER_TYPE=MOCK
BADGE_PRINTER_HOST=http://localhost:4567
Likewise, we have to mock PubNub, that's also done with a mock API server doing long polling.
For more details, we have a blog post for it
https://envoy.engineering/embedded-web-server-for-ios-ui-testing-8ff3cef513df
Anyway, in short, that's not for user interaction, it's more for changing the configuration to make some untestable thing testable for our use case.
We have a mocking recommendation, but unfortunately it is only supported on a very old RN version (0.44). Hang in there.
@leeor besides mocking, we also have use case for operations such as resetting key chain, for example, before certain test case, we want to reset the key chain, then we pass in
RESET_LOGIN=1
when the app reads this part, it will clear the key chain before launching the app. We can also set some variable, like access key
ACCESS_KEY=MOCK_ACCESS_KEY
As for our use case, it's not possible to reset key chain via user interface, we do have reset login, but that needs to be done via a toggle in Settings app.
Any reason not to use launch arguments? There is a similar API you can use to test whether a launch argument exists.
Most helpful comment
@leeor besides mocking, we also have use case for operations such as resetting key chain, for example, before certain test case, we want to reset the key chain, then we pass in
when the app reads this part, it will clear the key chain before launching the app. We can also set some variable, like access key
As for our use case, it's not possible to reset key chain via user interface, we do have reset login, but that needs to be done via a toggle in Settings app.