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

Remaining tasks

User interface changes

API changes

Data model changes

Comments

droplet created an issue. See original summary.

droplet’s picture

droplet commented
Issue summary: View changes
droplet’s picture

droplet commented
Issue summary: View changes
droplet’s picture

droplet commented
Issue summary: View changes
droplet’s picture

droplet commented
Issue summary: View changes
droplet’s picture

droplet commented
Issue summary: View changes

dotenv 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

Mixologic’s picture

Mixologic
He/Him/His
Primary language English
Location Portland, OR
commented

Im not sure what the goal with this issue is.

There are three different JS testing engines for drupal core

  1. PhantomJS JavascriptTestBase, which we want to deprecate and encourage everybody to stop using, because phantomjs is abandonware.
  2. DrupalSelenium2Driver: the webdriver Mink implementation that replaces the PhantomJS way that communicates with any Webdriver api service
  3. NightwatchJS: The 'being worked on as we speak' pure javascript testing environment.

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:

The twelve-factor app stores config in environment variables

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.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented
Status: Active » Closed (outdated)

As per #7 I think this is all configurable via environment variables now, given no further comments on this issue in many years I think it's time to close it out.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.