Problem/Motivation
JS test engine reading the env vars (getenv()). It increases the complexity of deploy to remote / sharing same config with team / cross-platform setup & docs. e.g.:
#2941560: Add testing with webdriver instructions for other operating systems
Also @see:
https://12factor.net/config
Proposed resolution
To develop a future-proof config that let webDriver easier to pick up different setting for different browsers (and test env). For example, we may run the IE test under Windows and Safari via remote MacOS.
Examples:
codeception
http://codeception.com/docs/modules/WebDriver
env:
chrome:
modules:
config:
WebDriver:
browser: 'chrome'
capabilities:
chromeOptions:
binary: "C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe"
args:
- start-maximized
- disable-per-monitor-dpi
- force-device-scale-factor
firefox:
modules:
config:
WebDriver:
browser: 'firefox'
As you can see above, with some case we have to pass args to disable unnecessarily config and things blocking the regular testing.
Then, running the test via command, for example:
yarn run js-test --firefox
yarn run js-test --custom-name-remote-A-preset
yarn run js-test --custom-name-remote-B-preset
Comments
Comment #2
droplet CreditAttribution: droplet commentedComment #3
droplet CreditAttribution: droplet commentedComment #4
droplet CreditAttribution: droplet commentedComment #5
droplet CreditAttribution: droplet commentedComment #6
droplet CreditAttribution: droplet commenteddotenv is popular in many scripting (Ruby / PHP Laravel / NodeJS), it should be considered:
https://symfony.com/doc/current/components/dotenv.html
https://www.npmjs.com/package/dotenv
Comment #7
MixologicIm not sure what the goal with this issue is.
There are three different JS testing engines for drupal core
Both 1, and 2 above *already have* a file based configuration, because they derive from phpunit. phpunit.xml.dist is where you configure those testing suites, and where any configuration that you would want set can become an environment variable, which, is the *recommended practice* according to the link you linked above:
For the pure NightwatchJS implementation, dotenv is already the strategy that is planned for implementing configuration.
So, I'm unsure what needs to be done, that hasn't already been done.